Doom Mathematic posted:What in the world does the Calibre codebase look like if its own maintainer thinks maintaining Python 2 is easier than migrating the codebase away from it from what i've heard, you really don't want to know i think it was a horror in this thread many years ago
|
|
# ? Nov 16, 2018 22:40 |
|
|
# ? Jun 7, 2024 04:22 |
|
Calibre's lead dev also doesn't give a poo poo about blatant security problems, so continuing to use a to-be-dead language shouldn't surprise anybody.
|
# ? Nov 16, 2018 22:41 |
|
Suspicious Dish posted:i guarantee you there will be a community maintained python 2 I can't wait for python 2 to be finally buried and done with. At least it's mostly looking like we won't have a perl 6 on our hands.
|
# ? Nov 17, 2018 05:04 |
|
McGlockenshire posted:Calibre's lead dev also doesn't give a poo poo about blatant security problems, so continuing to use a to-be-dead language shouldn't surprise anybody. Dat attitude
|
# ? Nov 17, 2018 19:53 |
|
Doom Mathematic posted:What in the world does the Calibre codebase look like if its own maintainer thinks maintaining Python 2 is easier than migrating the codebase away from it Calibre is great as an ebook/e-reader management tool but as a piece of software it's pretty gross.
|
# ? Nov 20, 2018 18:25 |
|
ToxicFrog posted:
All software is pretty gross.
|
# ? Nov 20, 2018 18:45 |
|
Remulak posted:All software is pretty gross. Certain programs like emacs and automake stand out as more gross than average. See: emacs yanking program state out of raw (virtual) memory wholesale, saving it to a temp file, then restoring it upon the program's next start.
|
# ? Nov 20, 2018 18:56 |
|
Paperboy posted:Certain programs like emacs and automake stand out as more gross than average. See: emacs yanking program state out of raw (virtual) memory wholesale, saving it to a temp file, then restoring it upon the program's next start. That’s what Smalltalk and many Lisps did, nothing weird about loading a virtual image. What Emacs does goes beyond that, though—it creates a new executable that contains the dumped image, so it doesn’t need to find and load the image at runtime.
|
# ? Nov 20, 2018 19:09 |
|
Zopotantor posted:That’s what Smalltalk and many Lisps did, nothing weird about loading a virtual image. It remains important for performance, cutting startup time from 5 seconds to less than .1 second as of March: https://dancol.org/pdumperpres.pdf The newer plan is more or less the dumped image version. All of Emacs is more or less a horror due to 36 years of backwards compatibility, though: https://www.facebook.com/notes/daniel-colascione/buttery-smooth-emacs/10155313440066102
|
# ? Nov 20, 2018 19:33 |
|
Somebody on this forums joked they'll make a Python 2.9 because GvR said there'd never be a Python 2.8 and I'm just waiting for it to happen. My problem in going to Python3 is the asshats insisting we target the earliest interpreter of the platforms we support. That is Python 3.3. So we will go from a just-deprecated version to one deprecated two years before.
|
# ? Nov 20, 2018 22:01 |
|
Python 2.9 except the entire changelog is an amendment to the spec that makes it say, in its entirety, "Python 2.9 is, by definition, the latest revision of Python 3 at any given time".
|
# ? Nov 20, 2018 23:15 |
|
Rocko Bonaparte posted:Somebody on this forums joked they'll make a Python 2.9 because GvR said there'd never be a Python 2.8 and I'm just waiting for it to happen. someone already started, and the PSF demanded they change the name. they chose "Tauthon", which is just under "Diaspora" in "really terrible names for things" https://github.com/naftaliharris/tauthon
|
# ? Nov 21, 2018 02:02 |
|
Suspicious Dish posted:someone already started, and the PSF demanded they change the name. they chose "Tauthon", which is just under "Diaspora" in "really terrible names for things" https://github.com/naftaliharris/tauthon Why don't they just call it Fighton?
|
# ? Nov 21, 2018 02:54 |
|
Suspicious Dish posted:someone already started, and the PSF demanded they change the name. they chose "Tauthon", which is just under "Diaspora" in "really terrible names for things" https://github.com/naftaliharris/tauthon Oh god, is this a tau-better-than-pi thing?
|
# ? Nov 21, 2018 04:03 |
|
rjmccall posted:Oh god, is this a tau-better-than-pi thing? I assume Rhothon and Sigmathon were voted down.
|
# ? Nov 21, 2018 04:55 |
|
ulmont posted:I assume Rhothon and Sigmathon were voted down. How about Phởton?
|
# ? Nov 21, 2018 04:56 |
|
Absurd Alhazred posted:How about Phởton? That's just silly. Also, Rho, Sigma, and Tau are the next letters following Pi.
|
# ? Nov 21, 2018 05:07 |
|
I still think FightOn is the better choice, but that's too self-aware for them to chose (also probably not as funny as it sounds in my head).
|
# ? Nov 21, 2018 05:09 |
|
Absurd Alhazred posted:I still think FightOn is the better choice, but that's too self-aware for them to chose (also probably not as funny as it sounds in my head). I'm thinking going for a mythological reference with the near homophone of that, Phaeton. Phaeton was the son of Apollo, and when he met his dad he went and tried to do Apollo's job of pulling the sun across the sky, but hosed it up royally. Apollo was the patron god of the oracle at Delphi, where the serpent Python was said to dwell. It's perfect.
|
# ? Nov 21, 2018 11:19 |
|
Tarezax posted:I'm thinking going for a mythological reference with the near homophone of that, Phaeton. Woah.
|
# ? Nov 21, 2018 14:53 |
|
To think this is the same community that gave us the Pantyshot naming fiasco.
|
# ? Nov 21, 2018 16:27 |
|
Do people count as coding horrors when they refuse to fix/improve a 2s stall in an "open-world" game whenever zoning to a new area? The stall was because gameplay was doing half a metric shitton of string comparisons instead of enum comparisons. For static data.
|
# ? Nov 21, 2018 21:44 |
Doing any amount of string comparisons in a game loop is a coding horror, unless you're making a typing/word game or something like that.
|
|
# ? Nov 21, 2018 22:02 |
|
Joda posted:Doing any amount of string comparisons in a game loop is a coding horror, unless you're making a typing/word game or something like that. Oh definitely, most of our systems are relatively sane but anything that deals with web requests just ends up being batshit insane because people keep thinking string parsing and later comparing them at runtime is less work than enums for some reason. There's also less bad but still ridiculous things like allocating a string to do a comparison because people never heard of strcmp (when a string comparison is actually needed, which is nearly never). This was just the most recent (and most terrible so far) issue I've come accross due to strings.
|
# ? Nov 21, 2018 22:32 |
|
Falcorum posted:Do people count as coding horrors when they refuse to fix/improve a 2s stall in an "open-world" game whenever zoning to a new area? Same co-worker you mentioned before? Or has the infection spread?
|
# ? Nov 22, 2018 06:42 |
|
Have they given any justification for refusing to fix this?
|
# ? Nov 22, 2018 07:38 |
|
Different co-worker unfortunately.ynohtna posted:Have they given any justification for refusing to fix this? He didn't consider it an issue. He got overruled in the end and it's fixed now but still
|
# ? Nov 22, 2018 20:42 |
|
Some people do not know they're types good.
|
# ? Nov 23, 2018 06:33 |
You are developing a Windows application for syncing user photos between a PC and your cloud service. Where would you store a local cache of files? A) In the user profile folder, Local AppData or similar B) In the shared user profile, C:\ProgramData or similar C) A folder under C:\Windows\System32 If your choice was C, then congratulations, you made the same choice as Apple did for iCloud. What the gently caress, Apple?
|
|
# ? Nov 23, 2018 11:37 |
|
nielsm posted:You are developing a Windows application for syncing user photos between a PC and your cloud service. Where would you store a local cache of files? Apple intentionally makes their Windows stuff extremely lovely. They probably were confronted with this very decision and made sure they chose the worst option.
|
# ? Nov 23, 2018 15:47 |
|
Speaking of knowing types and C (although the language rather than the drive / choice)... recently, I found a series of unfortunate events. Now, C++ supports C-style strings, and they are frequently used. As a reminder, C-strings are just an array of characters and must be null terminated to tell other code where the end is, so you have to be careful with them. Someone had been using C-strings and copying with strcpy; for those unfamiliar, strcpy will just copy a C-string from a source to a destination blindly without any bounds checking or null terminator checks. So, if you do this: C++ code:
Later, someone else changed these to strncpy to 'fix' the fact that the original version had used strcpy. Now, strncpy is not much safer than strcpy, but it does have a bounds that you set to limit the number of characters copied. One typical flaw you'll see with that is someone using sizeof(src). Interestingly, sizeof is typically a compile-time operation, so it's not a performance hit to use it instead of defines (which is why I'll change the code in the following snippets). It will give you the size of the object in bytes. This is perfectly fine for char (signed or unsigned) since that's always 1 byte length, but needs to be used with care on other types. Using the size of the source C-string for the bounds of the destination C-string is bad for obvious reasons... but that's not what happened here. The 'fix' was to make the bounds the value of strlen(dest), which was just declared prior to using the strncpy without initialization: C++ code:
1) strlen uses the null terminator to determine its length. 2) the recently-declared destination had not been initialized as empty, so any stray null terminator in the destination C-string would make strlen shorter than the actual size of the destination C-string. It might be possible to be longer, but I've not been able to get that situation to occur even with tiny C-strings. Maybe compilers these days are just smart enough to at least stick a null terminator somewhere in the C-string at declaration. A third person had then come and 'fixed' that 'fix' by changing the bounds for strncpy to the sizeof(dest): C++ code:
If the character at element 20 is not a null terminator, then any operation that relies on a null terminator will go off into wherever it runs into a 0 in memory. A typical solution to this issue is to just do this: C++ code:
C++ code:
The best practice is to always initialize a variable before you use it; so I prefer this solution: C++ code:
1) You will never use the destination C-string without initializing it. 2) The destination C-string will initialize filled with null terminators. 3) sizeof(dest) - 1 is compile-time and will never overwrite the last element (initialized to a null terminator previously) with anything. 4) Someone changing SMALL to 0 will trigger modern compilers that the array isn't big enough for the initialization and flag it as an error. I won't say this is the best way of dealing with this sort of legacy crap, but I think it's an improvement over what was there. e: There is one consideration I haven't mentioned - part of strncpy's shtick is to set bytes to 0 that it didn't fill (ex: copying a 20-element array to a 100-element array will fill zeroize the last 80 characters). This makes it slower than strcpy and above a certain threshold (a few thousand characters) slower even than snprintf. snprintf has nearly constant performance regardless of the size of the C-string, and will null terminate. It does have the same danger of strncpy on bounds, so you do need to make sure that's right. Evil_Greven fucked around with this message at 16:13 on Nov 23, 2018 |
# ? Nov 23, 2018 15:51 |
|
nielsm posted:You are developing a Windows application for syncing user photos between a PC and your cloud service. Where would you store a local cache of files? Apple has to assert its dominance in the host system
|
# ? Nov 23, 2018 15:57 |
|
Volte posted:Apple intentionally makes their Windows stuff extremely lovely. They probably were confronted with this very decision and made sure they chose the worst option. Nah, I'm sure that even on their MacOS they probably put those pictures in /sbin or /usr/sbin . Which is why, when they googled "system executables in windows" they stumbled over "c:\windows\system32".
|
# ? Nov 23, 2018 16:17 |
|
Evil_Greven posted:Now, C++ supports C-style strings, and they are frequently used. If your intent really is to truncate strings larger than the destination buffer, see if strlcpy() is available to you. In general though, I would recommend not using c-strings and fixed size buffers in c++ unless there is some hard constraint preventing you from using std::string. Without constant vigilance, people will repeat the mistakes you've described. Better to just just replace the legacy code with std::string imo.
|
# ? Nov 23, 2018 16:38 |
|
Illusive gently caress Man posted:If your intent really is to truncate strings larger than the destination buffer, see if strlcpy() is available to you. I'd like to replace the whole drat thing like you suggest, but we just do not have the time to do a complete overhaul. I'm fixing things incrementally as we have changes to make, killing warnings, etc. It's a slow process. Evil_Greven fucked around with this message at 16:44 on Nov 23, 2018 |
# ? Nov 23, 2018 16:42 |
|
Falcorum posted:He didn't consider it an issue. He got overruled in the end and it's fixed now but still drat. That boy needs to learn some righteous impatience. Reminds me when I was working on mid-90s games and a co-worker swore blind that their menu screens implementation - nothing fancy, just your bog standard simple full-screen non-animated 2D start, load, save, & options - was physically incapable of running faster than 4 FPS. Despite our sloppy vintage software rendering 3D engine (plus full game & audio systems) running at ~30 FPS on the same dev hardware, having the mouse cursor lag-teleport when the game was paused and only his UI code ran was simply the best that could be done.
|
# ? Nov 23, 2018 17:22 |
|
Evil_Greven posted:Speaking of knowing types and C (although the language rather than the drive / choice)... recently, I found a series of unfortunate events.
|
# ? Nov 24, 2018 00:05 |
|
Rocko Bonaparte posted:I mean, yeah, but this is just classic "stumbling in the dark with C." As opposed to, say, writing your own "optimized" strcpy that not only does not have any awareness of boundaries but has an off-by-one bug. I kind of wonder if folks just don't bother to make sure poo poo does what they think it will. It's not exactly hard to write a test program to verify assumptions on something like this, but c'est la vie .
|
# ? Nov 24, 2018 00:26 |
|
The last time I was prodding around in C++ was around 2010, but back then it really did look like a pain to unit test in C/C++. There was not much out there that would run the tests in another process to keep the suite running if something segfaulted, which I consider to be pretty important. But we both know that was not what hampers your colleagues . . .
|
# ? Nov 25, 2018 02:15 |
|
|
# ? Jun 7, 2024 04:22 |
|
libCheck is great for that in C, but you need to work with something else for C++ unless you catch SEH on Windows. Spooning with Boost.Test on a new project and will see how that copes.
|
# ? Nov 26, 2018 05:08 |