|
NihilCredo posted:I live in the blessed land of GC and exceptions. I thought that unsigned overflow was simply the codification of what would happen by default anyway if unsigned overflow were left as UB. Are there any architectures that need to specifically handle them because they would do weird things otherwise and not guarantee 255 + 2 = 1? Compilers will often do things like assuming that x + 1 > x is always true. That means they can omit the comparison entirely, ignore all the code that's only reached if that condition is false, etc. They can't do that if x + 1 can legitimately overflow and be smaller than x.
|
# ? May 20, 2019 09:24 |
|
|
# ? Jun 8, 2024 07:35 |
|
Absurd Alhazred posted:Ah, the OpenGL school of error handling. Love warning my graphics students 10000 times every year to expect their programs to fail silent on them no matter how hosed up their arrays that they built are, at draw time
|
# ? May 20, 2019 09:44 |
|
redleader posted:Gosh, imagine needing to know how many things you have in a collection. If you have a collection where you need to know the length, you don't use Haskell lists (which are just linked lists). You use Data.Vector or something similar, depending on the other requirements.
|
# ? May 20, 2019 17:15 |
|
|
# ? May 20, 2019 17:46 |
|
Eggnogium posted:Just lol at the idea that treating < 0 size lists like 0 size lists is defensive programming. IIRC you can have negative-length lists in Prolog. (It's always Prolog that has the weirdest things.) "Difference lists" are a hack to speed up operations like list concatenation. A difference list is represented as two parameters to a predicate which normally contain a list and a suffix (potentially uninstantiated) of that list. The pair represents the initial segment of the list up to the start of the suffix. code:
|
# ? May 20, 2019 18:18 |
|
Put that on my car please.
|
# ? May 20, 2019 18:21 |
|
I have two shirts with this
|
# ? May 20, 2019 20:42 |
|
I ♥ Unicode
|
# ? May 20, 2019 20:43 |
|
csammis posted:I have two shirts with this Are they equal to each other?
|
# ? May 20, 2019 21:06 |
|
CPColin posted:Are they equal to each other? One of them is in NFC and the other is in NFD
|
# ? May 20, 2019 21:43 |
|
Fatty Crabcakes posted:That's why this is a horror: it's an overly complicated way of doing it wrong. Imagine if you will someone wanting to do the shockingly complex task of command line arguments that set variables and set logging text for said variables. Now imagine that the solution to this task is using void pointers and pointer arithmetic from static functions to a shared class. Apparently, older versions of Visual Studio were more tolerant than more recent VS versions of someone doing this. Also, the people set to debug this never looked at the compile logs, so it went unfixed for months, using the older compiler version as a patch because 'that one works!' Evil_Greven fucked around with this message at 00:03 on May 21, 2019 |
# ? May 21, 2019 00:01 |
|
NihilCredo posted:I live in the blessed land of GC and exceptions. I thought that unsigned overflow was simply the codification of what would happen by default anyway if unsigned overflow were left as UB. Are there any architectures that need to specifically handle them because they would do weird things otherwise and not guarantee 255 + 2 = 1? UB is more than just "the compiler doesn't guarantee this". It means "the optimizer is allowed to assume this will never happen and use that assumption to rearrange code and generate slightly faster binaries that explode and fail horribly if it ever actually does." Unsigned overflow is defined though. It's just signed overflow which is UB.
|
# ? May 21, 2019 00:17 |
|
Hammerite posted:One of them is in NFC and the other is in NFD Did you just tell me to go gently caress myself?
|
# ? May 21, 2019 00:31 |
|
pokeyman posted:Did you just tell me to go NFKC myself? Or something...
|
# ? May 21, 2019 22:24 |
|
RPATDO_LAMD posted:UB is more than just "the compiler doesn't guarantee this". It means "the optimizer is allowed to assume this will never happen and use that assumption to rearrange code and generate slightly faster binaries that explode and fail horribly if it ever actually does." https://devblogs.microsoft.com/oldnewthing/?p=633 and the series http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html are good discussions of this
|
# ? May 22, 2019 05:42 |
|
RPATDO_LAMD posted:Unsigned overflow is defined though. It's just signed overflow which is UB. Ah, found the answer to this in that second link above. Very cool read
|
# ? May 22, 2019 05:56 |
|
The lifehack they won't teach you at University: get around all overflow issues by stringly typing your code.
|
# ? May 22, 2019 08:31 |
|
Hardware horror: when you have seven different timer peripherals on a system, and not a single goddamn one of them can generate an interrupt when the time matches a given reference point. Actually no - one of them can, but it takes 500us to write the reference value, making it completely worthless. gently caress
|
# ? May 24, 2019 15:21 |
|
Hello I'm debugging an ActiveX-JS integration in IE in the year of our lord and master satan 2019 please send thoughts and prayers!
|
# ? May 24, 2019 16:26 |
|
Spatial posted:Hardware horror: when you have seven different timer peripherals on a system, and not a single goddamn one of them can generate an interrupt when the time matches a given reference point. What's the hardware?
|
# ? May 24, 2019 16:44 |
|
Spatial posted:Hardware horror: when you have seven different timer peripherals on a system, and not a single goddamn one of them can generate an interrupt when the time matches a given reference point. The worst feeling ever
|
# ? May 25, 2019 00:30 |
|
Spatial posted:Hardware horror: when you have seven different timer peripherals on a system, and not a single goddamn one of them can generate an interrupt when the time matches a given reference point. you get to solve the problem a different way!
|
# ? May 25, 2019 19:38 |
|
Oh my god, another left-pad incidentNolgthorn posted:https://twitter.com/lukejacksonn/status/1131506699356037121 Except somehow the remotely depended-upon trivial code was even more trivial: quote:console.log('Smarty Smart Smarter');
|
# ? May 27, 2019 20:39 |
|
I'm sure someone will get fired over this. Not anyone who actually deserves it, mind you, but someone will be for sure.
|
# ? May 27, 2019 20:46 |
|
Here's where the outage was traced back to them: https://github.com/Unitech/pm2/issues/4289 quote:Unitech commented 4 days ago
|
# ? May 27, 2019 20:49 |
|
what's an "optional dependency" anyway
|
# ? May 27, 2019 20:49 |
|
Hammerite posted:what's an "optional dependency" anyway Not sure if serious, but: it's a dependency that adds some optional functionality that's not strictly required for your core functionality. For instance, the popular C++ image library OpenImageIO has an optional dependency on the popular C++ font rendering library Freetype. If you include Freetype in your OIIO build then you will produce an OIIO that can load font formats, otherwise it cannot load font formats. As a concept it's not that uncommon, half the libraries we use at work can be optionally build against TBB if you include that, or optionally target Hexagon DSPs if you include the Hexagon SDK, and so on. Adding dummy dependencies to badly track unspecified user statistics isn't one of the top uses I can think of.
|
# ? May 27, 2019 23:05 |
|
A dummy dependency is such a pointlessly roundabout "clever" way to gather usage statistics. A npm package can run arbitrary scripts when it's installed and you can just hit your analytics endpoint directly.
|
# ? May 28, 2019 00:23 |
|
this is compounded by optionalDependencies in npm, actually not being that, lmao
|
# ? May 28, 2019 00:56 |
|
So, um, my predecessor was self-taught, and by certain signifiers I can recognize elsewhere in the project, this code was written very early even by his standards. Which is all the explanation or context I can offer for this, the greatest piece of bad code I've ever seen in my life. Please know that this in a specially created Person.cs file inside App_Code, and that this is the entirety of the file except for the includes, I'm not cherry-picking. code:
|
# ? May 31, 2019 00:34 |
|
You have to be a People.Person to work there. but also CapnAndy posted:
I'm too new myself to feel confident saying this is as dumb as I think it is. It is, right? Dross fucked around with this message at 00:52 on May 31, 2019 |
# ? May 31, 2019 00:48 |
|
Dross posted:I'm too new myself to feel confident saying this is as dumb as I think it is. It is, right?
|
# ? May 31, 2019 00:55 |
|
CapnAndy posted:Declaring private variables just to get/set them with full permission public faces is extremely dumb, yes, although for the record they tried to drill that particular quirk into me in college because it's a best practice for some unfathomable reason -- I think just to get you used to the idea of getting and setting and that it can be done and to nudge you towards the idea that you can have whatever methods you like in there, or something. But yes, it's a waste of time. I think the "idea" is future proofing in case you later discover you need to do some input validation or change a private cached field on input or something, so you can amend your Set method without affecting existing correct code. This also is almost always foreseeable, or at least with experience you usually know when it might be the case in the future and can be defensive about it. Other than that? Just use a public field.
|
# ? May 31, 2019 01:16 |
|
Linear Zoetrope posted:I think the "idea" is future proofing in case you later discover you need to do some input validation or change a private cached field on input or something, so you can amend your Set method without affecting existing correct code.
|
# ? May 31, 2019 01:30 |
CapnAndy posted:Declaring private variables just to get/set them with full permission public faces is extremely dumb, yes, although for the record they tried to drill that particular quirk into me in college because it's a best practice for some unfathomable reason -- I think just to get you used to the idea of getting and setting and that it can be done and to nudge you towards the idea that you can have whatever methods you like in there, or something. But yes, it's a waste of time. it's because java's getter/setter implementation brain damaged an entire generation by requiring explicit getButts/setButts calls, instead of making them a language feature for easily overloading access and assignment like in a sane language
|
|
# ? May 31, 2019 01:46 |
|
CapnAndy posted:So, um, my predecessor was self-taught, and by certain signifiers I can recognize elsewhere in the project, this code was written very early even by his standards. It looks like it was automatically generated by some tool or other Signed, some tool or other
|
# ? May 31, 2019 10:31 |
|
Linear Zoetrope posted:This also is almost always foreseeable, or at least with experience you usually know when it might be the case in the future and can be defensive about it. Other than that? Just use a public field. In C# there's really no advantage to using public fields over properties, while there are a number of disadvantages*. You should always use public properties over fields, unless there is some explicit reason to use a field. *Fields cannot be part of an interface, properties allow for different access modifiers on get/set, properties can be computed, changing a field is always a breaking API change, just to name a few.
|
# ? May 31, 2019 11:10 |
|
CapnAndy posted:So, um, my predecessor was self-taught, and by certain signifiers I can recognize elsewhere in the project, this code was written very early even by his standards. If is is 'the greatest piece of bad code you've ever seen' you've lived either a charmed or a short life. Hammerite posted:It looks like it was automatically generated by some tool or other Not necessarily. My boss has the same pattern, because he simply starts every file by copy/pasting the #regions from a template file. He actually goes much further, his classes are structured like this: code:
And yes, I did show him how to use autoproperties but he still writes private fields and getters/setters
|
# ? May 31, 2019 11:27 |
|
If he wrote autoproperties, you wouldn't be able to see all the fields just by expanding the FIELDS section! What's an outliner?
|
# ? May 31, 2019 11:31 |
|
|
# ? Jun 8, 2024 07:35 |
|
Linear Zoetrope posted:I think the "idea" is future proofing in case you later discover you need to do some input validation or change a private cached field on input or something, so you can amend your Set method without affecting existing correct code. It's 100% because you used to have to write out all that crap by hand back in the dark ages of language version < 3 and someone internalized the only way as the only right way when the world moved on.
|
# ? May 31, 2019 14:28 |