So I decided to try to update part of my toolchain...
-
@Groaner said in So I decided to try to update part of my toolchain...:
24-bit RGB texture
Chances are that it became a 32-bit RGBX (perhaps swizzeled) as soon as you handed it over to GL/DX/whatever anyway.
-
@cvi said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
You only really need to know about the details at the level of assembly or lower, though this is what all the __declspec(dllexport) junk that you see (used to see?) in Windows C++ code is talking about.
__declspec(dllexport)
doesn't affect the calling convention, though. It just tells the compiler/linker that a symbol (or multiple symbols if you put it on a class) should be exported.Oh, right. It's been a while since I've had to deal with that.
-
@Groaner said in So I decided to try to update part of my toolchain...:
Whatever happened to "Be liberal in what you accept, be conservative in what you send?"
It got eaten by, "Make the lazy ass-developers do the right thing and fix their goddamn code."
-
@acrow said in So I decided to try to update part of my toolchain...:
Hm. Say, just how well does libc handle memory fragmentation these days?
It doesn't defragment existing allocations (that's insanely awkward to do without compiler support) so some patterns will fragment. But I think it uses a scheme with pools for small allocations of particular size ranges, and only goes to direct allocation once you're in the range of a system memory page or more.
Measure, don't guess.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Groaner said in So I decided to try to update part of my toolchain...:
Whatever happened to "Be liberal in what you accept, be conservative in what you send?"
It got eaten by, "Make the lazy ass-developers do the right thing and fix their goddamn code."
Or, "This legacy shit is making my code unnecessarily convoluted and hinders those using it properly. I'm going to deprecate it, but maybe the legacy mode should be opt-in, instead of opt-out, so that lazy idiots will take notice in the meanwhile."
Edit: missing words
-
@acrow said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Groaner said in So I decided to try to update part of my toolchain...:
Whatever happened to "Be liberal in what you accept, be conservative in what you send?"
It got eaten by, "Make the lazy ass-developers do the right thing and fix their goddamn code."
Or, "This legacy shit is making my code unnecessarily convoluted and hinders those using it properly. I'm going to deprecate it, but maybe the legacy mode should be opt-in, instead of opt-out, so that lazy idiots will take notice in the meanwhile."
Edit: missing words
I have some conversion tools that export assets as
.mesh
files and others as.MESH
. Right now, I'm trying to decide whether it's less work to go update each of their entries in the resource tables to match filenames on case and then deal with this same problem every time I add a new asset, or just recompile Ogre and its dependencies to useLEGACY
and be done with it.The filesystem doesn't care about this distinction, so why should we?
-
#CaseSensitivityWasAMistake
-
@Groaner said in So I decided to try to update part of my toolchain...:
The
filesystemMS Legacy Support Layer doesn't care about this distinction, so why should we?FTFY. The filesystem only cares of bytes. Byte values for character ranges A-Z and a-z differ greatly from each other. Pretending otherwise causes extra code, and thus extra bugs, with no real benefits.
Edit: typos
-
@acrow said in So I decided to try to update part of my toolchain...:
@Groaner said in So I decided to try to update part of my toolchain...:
The
filesystemMS Legacy Support Layer doesn't care about this distinction, so why should we?FTFY. The filesystem only cares of bytes. Byte values for character ranges A-Z and a-z differ greatly from each other. Pretending otherwise causes extra code, and thus extra bugs, with no real benefits.
Edit: typos
I dunno about you, but I consider the following file extensions being considered one and the same as a "real benefit."
.mesh .mesH .meSh .meSH .mEsh .mEsH .mESh .mESH .Mesh .MesH .MeSh .MeSH .MEsh .MEsH .MESh .MESH
The alternative is incredibly user-hostile. It's much the same reason why certain databases default to a case-insensitive collation.
-
@Groaner said in So I decided to try to update part of my toolchain...:
I dunno about you, but I consider the following file extensions being considered one and the same as a "real benefit."
I consider it a pain in the ass to maintain, pampering s , and a pain to explain to users, especially the meSH and MEsh permutations; they look different to the basic user, so "why doesn't Windows allow keeping a.meSH and a.MEsh in the same folder?" is what they'll ask.
AFAIK, all FAT32, exFAT and NTFS actually support having files that only differ in case. It's only Windows's legacy user-safety that tries to prevent the user from doing that. If you get a folder full of files from someone that uses Mac, Linux or Android, and two differ only by case, then you're going to have a problem in two ways. Either when Windows prevents you from un-zipping that folder, or when some software fails to grasp which one you want to open, since thay have (from its point of view) identical names. Guess who gets the support call?
The alternative is incredibly user-hostile. It's much the same reason why certain databases default to a case-insensitive collation.
If the OS, framework or database support case-insensitivity in searches or file-opening, then go for it. But maintaining support for it inside a piece of specialized software is easily surplus to requirements.
-
@acrow said in So I decided to try to update part of my toolchain...:
"why doesn't Windows allow keeping a.meSH and a.MEsh in the same folder?"
I wonder how many non-developers have that problem (though admittedly, regular users are less likely to run Linux or BSD, and Mac OSX or Windows are case-insensitive).
Just recently I had to help someone who couldn't believe that his Windows filesystem got turned case-sensitive and thus no longer could find certain files (it's a new feature to support WSL). Also we ended up with an
App.config
andapp.config
in the same directory, so which one is the right one, etc.
-
@JBert said in So I decided to try to update part of my toolchain...:
@acrow said in So I decided to try to update part of my toolchain...:
"why doesn't Windows allow keeping a.meSH and a.MEsh in the same folder?"
I wonder how many non-developers have that problem (though admittedly, regular users are less likely to run Linux or BSD, and Mac OSX or Windows are case-insensitive).
Just recently I had to help someone who couldn't believe that his Windows filesystem got turned case-sensitive and thus no longer could find certain files (it's a new feature to support WSL). Also we ended up with an
App.config
andapp.config
in the same directory, so which one is the right one, etc.Did Windows still want to hide file extensions when case-sensitive? Would be hilarious if did and two files' names differed only by the case of their extension.
-
@Groaner said in So I decided to try to update part of my toolchain...:
The alternative is incredibly user-hostile.
No. It's incredibly hostile to lazy devs who fuck up. Users don't usually see extensions at all, and “this has got to match exactly because computers are stupid and have no common sense at all” is a very easy rule to explain to those power users who take the leap to the second level of understanding.
-
@levicki
-
@levicki said in So I decided to try to update part of my toolchain...:
@Groaner said in So I decided to try to update part of my toolchain...:
I dunno about you, but I consider the following file extensions being considered one and the same as a "real benefit."
And I think we are long due for a filesystem which will:
- Get rid of file extensions alltogether
- Allow case sensitive file names because in written language you capitalize stuff properly and you should be able here too
- Require all applications to provide MIME type on file creation so that system can show the type instead of relying on extensions which can be inadvertently changed
- Require all applications to provide file size and longevity hint on file creation so that filesystem can minimize fragmentation
- Internaly use GUID for file access so that any number of files can have a same name -- you can have several identical books on the shelf in a store and there is no reason you should not be able to name all your photos and videos "2018 Vacation Tenerife" and keep them all in one folder.
- Allow creation of filesystem views which would group files and folders based on given search criteria.
At that point filenames will only be a bunch of tags which would actually have a real meaning to the user.
We'd have all that ages ago, if not for this pesky legacy thing (and people's biases and inability to think outside the box - you wouldn't believe how people here reacted the last time I proposed UID-only filesystem...)
-
@levicki said in So I decided to try to update part of my toolchain...:
Also, I use C++, not Rust.
The joke is that he hopes you'll switch over.
-
@levicki Why do you need to decode single jpeg image using multiple threads? Low-latency HD video transcoding?
-
@levicki said in So I decided to try to update part of my toolchain...:
- Allow case sensitive file names because in written language you capitalize stuff properly and you should be able here too
For this you don't need a case sensitive filesystem, you just need a case-preserving one. Windows and Mac OSX already do this and leave your uppercase characters where you last left them.
And if there is a file clash when filenames only differ in casing, maybe use spaces if it's made of several words (just don't allow any at the start or end of a filename). If you really want to use a CLI and your shell breaks on it, maybe get a better shell which auto-quotes the whole thing when using tab-completion.
-
@levicki said in So I decided to try to update part of my toolchain...:
@pie_flavor said in So I decided to try to update part of my toolchain...:
@levicki
- Is it multi-threaded?
Yes, using librayon.
- Does it handle RST markers?
It's got a handy enumeration of everything it doesn't support:
And restart markers are notably absent.
Also, I use C++, not Rust.
I mean you could probably shove a C shim on top of it, but what I was mostly pointing out was that third party libraries exist.
-
@levicki said in So I decided to try to update part of my toolchain...:
@Groaner said in So I decided to try to update part of my toolchain...:
I dunno about you, but I consider the following file extensions being considered one and the same as a "real benefit."
And I think we are long due for a filesystem which will:
- Get rid of file extensions alltogether
- Allow case sensitive file names because in written language you capitalize stuff properly and you should be able here too
- Require all applications to provide MIME type on file creation so that system can show the type instead of relying on extensions which can be inadvertently changed
- Require all applications to provide file size and longevity hint on file creation so that filesystem can minimize fragmentation
- Internaly use GUID for file access so that any number of files can have a same name -- you can have several identical books on the shelf in a store and there is no reason you should not be able to name all your photos and videos "2018 Vacation Tenerife" and keep them all in one folder.
- Allow creation of filesystem views which would group files and folders based on given search criteria.
At that point filenames will only be a bunch of tags which would actually have a real meaning to the user.
I'm not sure if you're being serious, or...?
- Extensions, being text suffixes, are inherently portable, encapsulating the MIME purpose as well as any other implementation.
- All file systems newer than FAT-16 support case-sensitive names already.
- Inadvertent change is dependent on UI, and ONLY UI, no matter what the underlying system.
- This has been tried: https://thedailywtf.com/articles/Classic-WTF-The-Bug-That-Shut-Down-Computers-WorldWide
- What's wrong with just plopping them all in a folder named "2018 Vacation Tenerife"? This is what folders were invented for.
- Tools are sold for this (for Windows, at least).
-
@acrow said in So I decided to try to update part of my toolchain...:
If you get a folder full of files from someone that uses Mac, Linux or Android, and two differ only by case, then you're going to have a problem in two ways.
- That person may be in a different city, country or part of the world, and
- Even if they were local, it's illegal in most jurisdictions to hit them with a lead pipe until they stop generating files that only differ in case.
-
@acrow said in So I decided to try to update part of my toolchain...:
- Extensions, being text suffixes, are inherently portable, encapsulating the MIME purpose as well as any other implementation.
Yes, but your primary target is usability, not portability. What is the advantage of conveying the file name and file type in the same text string? If you've already got the concept of separating a string and the contents of the file, surely you can add more. If you only judge a system based on how well it works with existing systems, you will never do anything new.
- Inadvertent change is dependent on UI, and ONLY UI, no matter what the underlying system.
Assuming, of course, that file extensions are standardized.
.part01.rar
anyone?Right, but that's a fail-hard scenario. 4 was about hinting, to increase optimization.
- What's wrong with just plopping them all in a folder named "2018 Vacation Tenerife"? This is what folders were invented for.
That's one particular example. There's plenty more. The point is that the user friendly name of the file should not correspond to the thing that programs use to uniquely identify it.
As a software industry over the past decade we've learned that presentation and behavior should be completely separated. Android developers are encouraged to use XML layouts instead of writing them in Java, inline style attributes are moving towards deprecation in HTML, UWP apps aren't 1:1 with the underlying .exe file, etc. There are only a few places where we continue to mix presentation and behavior, and one of them is filesystems.
-
@pie_flavor said in So I decided to try to update part of my toolchain...:
There are only a few places where we continue to mix presentation and behavior, and one of them is filesystems.
No. You're just so used to the presentation that you don't see it as anything but.
-
@acrow said in So I decided to try to update part of my toolchain...:
"why doesn't Windows allow keeping a.meSH and a.MEsh in the same folder?"
You must deal with Windows users who started on Unix. Every (non-dev) windows user I've met wouldn't understand why they didn't get the file they wanted when they clicked ".meSH" instead of ".MEsh". And if asked if they wanted to create a ".MEsh" file, they'd look at you sideways and say "but I already have a ".mesh" file.
-
@dkf said in So I decided to try to update part of my toolchain...:
@pie_flavor said in So I decided to try to update part of my toolchain...:
There are only a few places where we continue to mix presentation and behavior, and one of them is filesystems.
No. You're just so used to the presentation that you don't see it as anything but.
As long as file's identity is file's name, there will be a mixup of presentation and behavior in filesystems (or filesystem driver, or OS resource access layer, depending on how you feel today).
-
@acrow said in So I decided to try to update part of my toolchain...:
full of files from someone that uses Mac, Linux or Android,
We go bust a cap into that asshole who checked in a "makefile" and a "Makefile".
-
@pie_flavor said in So I decided to try to update part of my toolchain...:
@acrow said in So I decided to try to update part of my toolchain...:
- Extensions, being text suffixes, are inherently portable, encapsulating the MIME purpose as well as any other implementation.
Yes, but your primary target is usability, not portability. What is the advantage of conveying the file name and file type in the same text string? If you've already got the concept of separating a string and the contents of the file, surely you can add more.
I think before that we need to fix Open With to include all of Windows' special handlers, so I can use that instead of renaming files. (i.e. Right now the only way I know of to get Windows to open an EPUB file with its ZIP handler, so I can view the contents, is to rename it.) Once that's implemented then this might be usable; but there's no way in hell I can remember the MIME type for either EPUB or ZIP to switch those around instead.
-
@hungrier said in So I decided to try to update part of my toolchain...:
, it's illegal in most jurisdictions to hit them with a lead pipe until they stop generating files that only differ in case.
But a jury of your peers will never convict you. They may convict the victim.
-
@Unperverted-Vixen said in So I decided to try to update part of my toolchain...:
Right now the only way I know of to get Windows to open an EPUB file with its ZIP handler, so I can view the contents, is to rename it.)
Use 7zip. Its context menu "Open Archive" will open an EPUB just fine.
-
@Unperverted-Vixen I use TC4Shell, which adds 'Open as Folder' to the context menu for any file. Like what @dcon said, except it still opens it in Explorer.
-
@levicki said in So I decided to try to update part of my toolchain...:
@pie_flavor said in So I decided to try to update part of my toolchain...:
@levicki
- Is it multi-threaded?
- Does it handle RST markers?
Also, I use C++, not Rust.
He's like the StackOverflow guys who tell you to just use jQuery for everything.
-
@pie_flavor said in So I decided to try to update part of my toolchain...:
but what I was mostly pointing out was that third party libraries exist.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
He's like the StackOverflow guys who tell you to just use jQuery for everything.
Hmmm ... maybe he should replace his avatar with something like a boxing glove ...
-
@boomzilla Not really; jQuery is full of downsides and using Rust over C++ has zero downsides.
-
@pie_flavor said in So I decided to try to update part of my toolchain...:
@boomzilla Not really; jQuery is full of downsides and using Rust over C++ has zero downsides.
Uh huh.
-
@boomzilla you're welcome to name one.
-
@pie_flavor none of your developers know rust.
-
@boomzilla That's not a problem with the language; that's a problem with your developers. If you evaluate a language based on whether or not your developers know it, then every single language other than the one you've used so far is a bad choice. Even if it's Node.
-
@pie_flavor said in So I decided to try to update part of my toolchain...:
@boomzilla That's not a problem with the language; that's a problem with your developers. If you evaluate a language based on whether or not your developers know it, then every single language other than the one you've used so far is a bad choice. Even if it's Node.
You said:
@pie_flavor said in So I decided to try to update part of my toolchain...:
using Rust over C++ has zero downsides.
If you didn't mean it then that's fine. When you get out into the real world you'll learn important stuff like this.
-
@pie_flavor said in So I decided to try to update part of my toolchain...:
@boomzilla you're welcome to name one.
Existance of mature libraries for everything under the sun and tool ecosystem?
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@pie_flavor none of your developers know rust.
That's only a temporary issue.
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@pie_flavor none of your developers know rust.
That's only a temporary issue.
Life is only a temporary issue.
-
@boomzilla you're welcome to solve it for yourself.
-
@Gąska not necessary. It's self correcting.
-
@Carnage Rust can bind to C, so in fact with very little effort Rust has a shit ton more libraries than crates.io would suggest. I would say the IntelliJ plugin or VS Code plugin is enough tools for most people.
-
@boomzilla What you are saying is not related to what I was saying. There is no downside to using Rust. There may be a downside to making certain people use Rust, but not to use Rust in general.
-
@pie_flavor said in So I decided to try to update part of my toolchain...:
What you are saying is not related to what I was saying.
But it was absolutely related to what you said. You just didn't say all of what you meant to say.
There may be a downside to making certain people use Rust, but not to use Rust in general.
No one uses anything in general.
-
@boomzilla do you have any actual information to impart, or are you just going to keep being obtuse?
-
@acrow said in So I decided to try to update part of my toolchain...:
It's only Windows's legacy user-safety that tries to prevent the user from doing that. If you get a folder full of files from someone that uses Mac, Linux or Android, and two differ only by case, then you're going to have a problem in two ways.
macOS wouldn't let you have
file.meSH
andfile.MEsh
either.
-
@pie_flavor said in So I decided to try to update part of my toolchain...:
@boomzilla do you have any actual information to impart, or are you just going to keep being obtuse?
I imparted the information but you are determined to either ignore it or assume people could read your mind. This is what some call a personal problem.