WTF Bites
-
@HardwareGeek I don't tend to be prone to wanton capitalization, you know.
-
@pie_flavor said in WTF Bites:
@HardwareGeek I don't tend to be prone to wanton capitalization, you know.
But it's Fun! Who Doesn't want Random words being Elevated?
-
@anotherusername said in WTF Bites:
@pie_flavor said in WTF Bites:
@PleegWat My school had a mandatory math test administered in eleventh grade (created by the school). Notable questions:
'How would you write 3/5 as a decimal?'
I couldn't get this to work with either inline styles nor combining Unicode characters, so here's a png.
_
0.59Old-school, but clever.
I tried
style=text-decoration:overline, which I think got stripped, and inserting the html escape sequence for a Unicode combining mark (because pasting the Unicode character from somewhere didn't seem to combine). That put the overline way too low so you could really tell it apart from the actual character.
-
@Tsaukpaetra said in WTF Bites:
@pie_flavor said in WTF Bites:
@HardwareGeek I don't tend to be prone to wanton capitalization, you know.
But it's Fun! Who Doesn't want Random words being Elevated?
You work at now?
I’ve typed that 3 times already and you continue to try and correct it. The language is set to English, what the heck are you doing?
STAAAAHP
-
@topspin Just install another keyboard.
-
@Lorne-Kates said in WTF Bites:
So that's the open source version of "I can just get my code with a single menu click".
But don't you see? The open source version lets you get your code with no menu clicks!
-
@Zecc There is something cathartic about seeing all the libraries compile into each other that you just don't get from a big progress bar.
-
@pie_flavor I thought cargo now showing a progress bar was something of a minor celebration recently?
-
@pie_flavor said in WTF Bites:
@HardwareGeek I don't tend to be prone to wanton capitalization, you know.
AFAIK, German Grammar capitalizes Anything that fits the Definition of a Noun in a Sentence, instead of just proper Nouns.
-
@djls45 I don't believe "Anything" counts as a noun. Certainly "etwas" isn't capitalised.
-
@kazitor Ah, TIL; but, see, I am applying the German Rule to English Sentences, and in English, "Anything" is a Noun.
-
" It's been a few weeks since we've made changes to Gmail UI. What should we do next? "
" Hmm. How about some buttons over the email snippets shown on the inbox? We could make them only appear on mouse hover. "
" I don't know. What do you have in mind, exactly? "
" We could make them appear without a timeout so that it'll totally catch by surprise someone who's distractedly clicking the entry to open the email. "
" Okay, okay. What else? "
" One of them could be a delete button with no confirmation, other than an easy to miss undo dialog at the bottom of the screen!"
" Nice! Ship it!"
PS: " Just make sure it's somewhat aligned with the "has attachment" icon so we can trip people trying to use that as a guide. "
-
@djls45 No, it's a pronoun.
-
@kazitor ...Which is a sub-Category of Nouns.
-
@djls45
Not quite. Pronouns substitute a noun.
-
@djls45
Not quite. Pronouns substitute a noun. And as Such It fulfills All the same Qualities and Functions as a Noun, Which means It fits the Definition of a Noun, Which means It IS-ANoun.
-
Apparently to a certain class of person, the problem is not doing the calculation but extracting it from the question. Which is exactly the reason they use story questions.
For me personally the problem was mostly that it had numbers in it. I failed every single maths class I did up to University, where I discovered to my continued amazement that higher maths was a breeze. I was top of my class for Advanced Calculus II...for someone that got an 'ungradable' on A-level math.
I still can't do any mental maths, making change requires fingers (seriously)...brains are weird!
-
@Cursorkeys said in WTF Bites:
making change requires fingers
Well obviously, how else would you manipulate your coins?
-
@djls45 Pronouns are not capitalized, anyways.
-
Today's
showing that VS developers must be mods here (
):1>foo.obj : error LNK2022: metadata operation failed (801311E4) : Duplicate managed types have different visibilities. 1>LINK : fatal error LNK1255: link failed because of metadata errorsWhich types? Which visibility for each? Who knows? Who cares? Why would you expect a compiler that has just detected a problem to actually tell you where it found the problem?
Something broke. Somewhere. Go figure.
And that story (and its developers-
side-story of it taking weeks to be solved) has a happy ending, even though it's laced with even more !After a sufficient number of "I'm not happy" emails, someone finally took a good look at it. Apparently at least 2 other people got the error (in addition to one of the build farms, but not the other, but since it's apparently random that's not so surprising) but no one but me complained, so that's yet another
for my cow-orkers.But it got fixed!
In the end, apparently, the issue was that depending on the order in which compilation happened, the visibility of a couple of types wasn't the same. So apparently C# makes it possible to have non-deterministic code compilation, since the same code on different computers randomly happens to pick files in one order or another and produce different code (one that causes an error, one not).
Apparently, we have one file that declares an unmanaged type, without
#make_publicon it (so the type is not public). That file is included in 2 different files of another library, one that does#make_publicon the type, one that does not. If I understand it correctly, when the file with#make_publicis scanned first, the type is made public, and when the second file is scanned, the type is already known (and public) and all is fine because the second file doesn't specify the expected visibility of the type. But if the second file (with#make_public) is scanned first, then the type is not already known and is thus defined with the default visibility (not public), so when the first file is scanned afterwards, the type is already known and not public, so when the file says it should be public (due to#make_public), there is a conflict.I'm not sure whether it's yet another C#/VS/...
, or yet another other-devs for butchering the language, since I don't know enough about it...
-
@djls45 Pronouns are not capitalized, anyways.
Apart from at the start of a sentence, I can think of at least two that must be.
-
I couldn't get this to work with either inline styles nor combining Unicode characters, so here's a png.
Oh look: 0.59̅ works for me…
-
Looks better than when I tried myself but worse than in your screenshot.
(On a FF/Linux now, tried on FF/macOS yesterday)
-
Looks better than when I tried myself but worse than in your screenshot.
Since it seems to be the same font, I'm guessing that that's due to differences in the font rendering engine itself. Can't do much about that except perhaps to point and laugh, if that would help?
-
Ship it!
-
In the end, apparently, the issue was that depending on the order in which compilation happened, the visibility of a couple of types wasn't the same. So apparently C# makes it possible to have non-deterministic code compilation, since the same code on different computers randomly happens to pick files in one order or another and produce different code (one that causes an error, one not).
Apparently, we have one file that declares an unmanaged type, without
#make_publicon it (so the type is not public). That file is included in 2 different files of another library, one that does#make_publicon the type, one that does not. If I understand it correctly, when the file with#make_publicis scanned first, the type is made public, and when the second file is scanned, the type is already known (and public) and all is fine because the second file doesn't specify the expected visibility of the type. But if the second file (with#make_public) is scanned first, then the type is not already known and is thus defined with the default visibility (not public), so when the first file is scanned afterwards, the type is already known and not public, so when the file says it should be public (due to#make_public), there is a conflict.That's much less crazy than I expected. I'm glad to hear you solved the problem without
format c:.I'm not sure whether it's yet another C#/VS/...
, or yet another other-devs for butchering the language, since I don't know enough about it...100% C#/VS WTF. If the error is caused by code, it absolutely should report which part of code caused the error. When you first mentioned it, I thought it's some internal issue with the compiler caused by things outside of developers' control - contrary to popular belief, these things happen, and when it happens, there's really not much you can do except hope that replacing a thing with a theoretically exact duplicate will magically make the problem go away.
-
I omitted the age of the pupils: 16 to 19.
Oh. That would explain why my boss has trouble teaching how to solve simple linear systems to first year university students.
-
100% C#/VS WTF.
I'm glad to hear it.
If the error is caused by code, it absolutely should report which part of code caused the error.
Yeah, that part really annoys me. How can someone develop a compiler that just says "an error occurred somewhere" without giving more info?
Also, I'm both annoyed and worried at the idea that the same code can be compiled in two different ways depending on random factors (the order in which files are picked up), because while in this case it caused a very visible compilation error, who's to say that it might not create more subtle bugs in other cases? If the order in which files are processed matters (and I can understand that it does), then the compiler should ensure that there is a consistent, deterministic and always reproducible order. Anything else seems horribly wrong to me.
-
Also, I'm both annoyed and worried at the idea that the same code can be compiled in two different ways depending on random factors (the order in which files are picked up), because while in this case it caused a very visible compilation error, who's to say that it might not create more subtle bugs in other cases? If the order in which files are processed matters (and I can understand that it does), then the compiler should ensure that there is a consistent, deterministic and always reproducible order. Anything else seems horribly wrong to me.
C++ says hi.
-
But C# is supposed to be a better alternative to C++.
-
@Zerosquare it is... until you delve into unmanaged code.
-
C++ says hi.
I never had this issue with C++. At least, not with the build systems that I use. So maybe it's something that make, CMake, qmake, VS... all take care to solve in the case of a C++ project, but I never had to worry about the exact same code generating different results when compiled on two different computers.
So whichever level this is solved, C++ projects manage to do it (as far as I know), therefore why can't a C# project do it as well?
(note that I don't complain about generated code being dependent of the order in which files are processed, but rather about this problem combined with a build system that doesn't reproducibly process files in the same order)
-
@Gąska: The problem doesn't seem to be directly related to the fact it's unmanaged, does it?
-
@Zerosquare said in WTF Bites:
@Gąska: The problem doesn't seem to be directly related to the fact it's unmanaged, does it?
Apparently, we have one file that declares an unmanaged type, without #make_public on it (so the type is not public).
-
@Gąska: I know, that's why I said "directly-related". Non-determinism is a bigger problem. Unless I'm missing something, a similar problem could have occurred with managed code.
-
C++ says hi.
I never had this issue with C++. At least, not with the build systems that I use. So maybe it's something that make, CMake, qmake, VS... all take care to solve in the case of a C++ project, but I never had to worry about the exact same code generating different results when compiled on two different computers.
So whichever level this is solved, C++ projects manage to do it (as far as I know), therefore why can't a C# project do it as well?
(note that I don't complain about generated code being dependent of the order in which files are processed, but rather about this problem combined with a build system that doesn't reproducibly process files in the same order)
Order of include files can matter (at least in theory) but is usually manual.
Linker order can matter as well and tends to be automated. But that's only if the same symbol is exported by multiple object files?
Of course my experience is C not C++ so YMMV.
-
C++ says hi.
I never had this issue with C++. At least, not with the build systems that I use.
More precisely - not with the code you use. C++ leaves plenty of opportunity for semi-nondeterministic compilation. Global initialization fiasco, argument-dependent lookup coupled with operator overloads for 3rd party types, circular dependencies between libraries... I've had to deal with all of these, and some more, and it really isn't pretty. It's 100% avoidable, however, if the programmers simply don't write bad code. But many do, and when the bad code is in your dependencies, there's not much you can do.
(note that I don't complain about generated code being dependent of the order in which files are processed, but rather about this problem combined with a build system that doesn't reproducibly process files in the same order)
Then you're doing it wrong. You should absolutely complain about that order matters. Because it's completely beyond developer's control. If the order matters, whether it's deterministic or not, someone will always get hurt. If the order doesn't matter, there's nothing that can go wrong.
-
@Zerosquare said in WTF Bites:
@Gąska: I know, that's why I said "directly-related". Non-determinism is a bigger problem. Unless I'm missing something, a similar problem could have occurred with managed code.
My understanding is that it'd never occur with managed code because there's no situation where you'd ever need to use this
#make_publicconstruct, or declare the same type several times.
-
C++ says hi.
I never had this issue with C++. At least, not with the build systems that I use.
More precisely - not with the code you use. C++ leaves plenty of opportunity for semi-nondeterministic compilation. Global initialization fiasco, argument-dependent lookup coupled with operator overloads for 3rd party types, circular dependencies between libraries... I've had to deal with all of these, and some more, and it really isn't pretty. It's 100% avoidable, however, if the programmers simply don't write bad code. But many do, and when the bad code is in your dependencies, there's not much you can do.
We're circling around the two points I mentioned below, and I still feel the situation is not the same. Sure, all these things you mentioned exist (in bad code, which is why I asked before if the C# error I saw was due to bad code on our side), so yes, there is some "order of compilation matters" in C++. But I never contested that. What I still don't see, however, is a C++ project using any of those where in practice the compilation (linking, whatever) happened in different orders when the same code is compiled on different computers. So it might just be that the C++ build systems are not smart enough to do enough things in parallel (they parallelize compilation but not linking or whatever), but whichever way you cut it, the end result is that a given project, in my experience, is always compiled the same way.
(note that changing something in the project may cause the order of the build to change and that might trigger the issues you mentioned, yes, and this is indeed a bad thing, but this is slightly different, and slightly less worse IMO, than the exact same code being compiled differently)
(note that I don't complain about generated code being dependent of the order in which files are processed, but rather about this problem combined with a build system that doesn't reproducibly process files in the same order)
Then you're doing it wrong. You should absolutely complain about that order matters.
I should have said that in this specific rant, I'm not complaining about that. I don't like it and indeed would prefer it not to be the case, but whenever that happens, right now, I'm more angry at the build system not being able to deterministically reproduce the same results than at order mattering. Partly because fixing one of those requires (probably) changes to the language itself so it's unlikely to happen, whereas the other is an implementation issue in the compiler/build system.
-
How can someone develop a compiler that just says "an error occurred somewhere" without giving more info?
Some of the stages of a modern compiler can really munge around the code, making it extremely difficult to relate the location of the problem as seen by the compiler back to anything that the user might possibly hope to understand. It doesn't excuse it though; it just means that (quite a lot of) extra work has to be done to track each piece of code back to where it originated from.
-
@remi personally, I've had some non-deterministic compilation issues once due to bug in ccache (a program that caches GCC compilations so that full rebuilds become faster by not actually being full rebuilds). I believe there was also one other thing, but can't remember what it was or what caused it exactly, so for now, I agree that indeed the C++ toolchains don't exhibit such non-determinism. Though I wonder if there really wasn't anything different between the machines at your work. Maybe VS update version or something?
-
How can someone develop a compiler that just says "an error occurred somewhere" without giving more info?
Some of the stages of a modern compiler can really munge around the code, making it extremely difficult to relate the location of the problem as seen by the compiler back to anything that the user might possibly hope to understand. It doesn't excuse it though; it just means that (quite a lot of) extra work has to be done to track each piece of code back to where it originated from.
I guess I understand that it might be hard, but it would seem like one of the basic requirements of a compiler error. It's like saying "we're writing a warehouse inventory system, and when a storage bay is full it's hard to tell the warehouse manager which one it is, so we won't bother doing that extra work".
-
@remi personally, I've had some non-deterministic compilation issues once due to bug in ccache
Which as you clearly say was a bug in ccache. I'm just saying that if that happens with a given tool, then the tool is at fault for not trying to work around the limitations of the language.
Anyway, I'm mostly venting my frustration at that issue that took far too long to be solved. It's not a well thought-out and reasoned critique of C++ or C#.
Though I wonder if there really wasn't anything different between the machines at your work. Maybe VS update version or something?
Could be, to be honest I'm not in the same office as the other affected persons and I'm not going to spend days on that, so we'll probably never know.
Note that your remark also highlights something that I see as a short coming of VS, it's much harder to ensure everyone uses exactly the same version of all the tools, whereas on Linux we have a common folder that includes gcc and a given version of the stdlibc++ (and everything else) and this way all Linux developers use exactly the same version of almost everything (there are still exceptions and possibly bugs that would be at the kernel level or hardware drivers, but at least we don't have compiler discrepancies issues).
-
I guess I understand that it might be hard, but it would seem like one of the basic requirements of a compiler error.
Yes, which is exactly why I wrote:
It doesn't excuse it though; it just means that (quite a lot of) extra work has to be done to track each piece of code back to where it originated from.
-
@remi personally, I've had some non-deterministic compilation issues once due to bug in ccache
Which as you clearly say was a bug in ccache. I'm just saying that if that happens with a given tool, then the tool is at fault for not trying to work around the limitations of the language.
Your problem is a bug in VS compiler/linker/whatever. It's the exact same problem, except VS is 1st-party and ccache is 3rd-party. You wrote a valid code, and the compiler/linker/whatever messed up.
Anyway, I'm mostly venting my frustration at that issue that took far too long to be solved. It's not a well thought-out and reasoned critique of C++ or C#.
Fair enough.
-
Version 1 guids, iirc, are at least partial-orderable by time.
Fun fact: you can define a total order on any finite set. There may be no reason to choose one particular total order above another, but depending on your use case (ordered containers were mentioned), an arbitrary order may do just as well.
-
@djls45 Pronouns are not capitalized, anyways.
Apart from at the start of a sentence, I can think of at least two that must be.
If you're talking about English pronouns, I can think of only "I."
If you mean German pronouns, I think there's four ("Sie," "Ihnen," "Ihrer," and "Ihr"), unless you're combining separate forms as a single word.
-
@djls45 Pronouns are not capitalized, anyways.
Apart from at the start of a sentence, I can think of at least two that must be.
If you're talking about English pronouns, I can think of only "I."
If you mean German pronouns, I think there's four ("Sie," "Ihnen," "Ihrer," and "Ihr"), unless you're combining separate forms as a single word.There's also "Du" (mainly capitalized in letters only), but admittedly I didn't know what he might be alluding to before you mentioned it.
-
I should have said that in this specific rant, I'm not complaining about that. I don't like it and indeed would prefer it not to be the case, but whenever that happens, right now, I'm more angry at the build system not being able to deterministically reproduce the same results than at order mattering. Partly because fixing one of those requires (probably) changes to the language itself so it's unlikely to happen, whereas the other is an implementation issue in the compiler/build system.
You can turn off parallel project builds in C#, forcing them to always be built in the same sequential order. (How badly this will hurt your compilation times will depend on how beefy your build machine is and how many projects you have.)
I've never seen a case where order changes within a project. That's not what's going on here, right? Or did I misunderstand?
(Although I've also only paid attention to that with legacy .csproj files. I guess things might be different in the new format where it just wildcards the files to include.)
Note that your remark also highlights something that I see as a short coming of VS, it's much harder to ensure everyone uses exactly the same version of all the tools, whereas on Linux we have a common folder that includes gcc and a given version of the stdlibc++ (and everything else) and this way all Linux developers use exactly the same version of almost everything (there are still exceptions and possibly bugs that would be at the kernel level or hardware drivers, but at least we don't have compiler discrepancies issues).
You can force a specific compiler version to be used by installing the relevant Microsoft.Net.Compilers package in your projects.
As for the standard library, it behaves like you want if you're using .NET Core (since you ship the version you built against). If you're using the full framework, since it's installed on the end user's machine rather than shipping with the product, there's no way to lock it to a specific version.
-
If you're talking about English pronouns, I can think of only "I."
God also thinks that He should be capitalised when referring to, er - it seems I missed a few in my eagerness to be pedantic, Himself.
