Okay, so let's not do the human trials. Just be content with the modelling (which is known to be imprecise especially where it matters most), and just approve the drug. What would that even solve? Instead of 6 volunteers getting injured, all the customers/patients who bought and took the drug would get harmed.
There is always human trial — the whole history/timeline of people taking a particular medicine is effectively a decades-long human trial. That's actually the only way we learn about long-term side effects, see paracetamol for instance. All you're proposing is we remove a smaller, controlled pre-trial before releasing the medicine into the wilder population. Sorry, but that won't solve anything except for your feeling of moral indignation.
> Debian isn't really trying to lead the charge on making it possible to install arbitrary apps. In fact they're mildly hostile to the idea.
I, for one, welcome our Debian overlords, taking care of stupid users such as myself to protect them from both "arbitrary" applications and from non-obsolete versions of non-arbitrary applications.
And yes-yes, this curated walled-off garden is fine, unlike all others walled-off gardens, because its maintained by "the community" (of Debian maintainers, that is).
Are the Debian devs preventing you from running software on your machine?
They even document how to create your own packages, and running your own repositories.
It is the future, and has been the future for almost 40 years already! I bet that's what the hoverboards will use inside their microcontrollers — gotta drive those portable fusion reactors reliably!
Next thing, you're going to argue that when the US sanctioned the whole population of Crimea back in 2014, that also was "a poorly thought-out virtue-signalling knee-jerk" reaction that worsened, for no good reason, the situation of the helpless Ukrainians who had happened to live there and now also had to live under Russia's brutal rule and face the international isolation. But you'd be wrong.
Hey, it's not enough that your own government oppresses you — you better get some additional oppression from the overseas, just to make sure you know they have your best interests at their heart, honest-honest.
> I can directly inspect the result of the preprocessor makes macros easier to debug
Tangential note but: why does this require a separate re-invocation of the compiler with the '-E' flag? Say I have this silly example with a comma instead of the semicolon inside W() macro:
#define W(a, b) b, int a
#define X(a, b) W(b, a)
int kekw(int x) {
int z = X(23, k) = x;
return z + k;
}
When I shove it into GCC without -E, it says
: In function 'int kekw(int)':
:1:21: error: expected unqualified-id before 'int'
1 | #define W(a, b) b, int a
| ^~~
:2:18: note: in expansion of macro 'W'
2 | #define X(a, b) W(b, a)
| ^
:5:13: note: in expansion of macro 'X'
5 | int z = X(23, k) = x;
| ^
:6:16: error: 'k' was not declared in this scope
6 | return z + k;
|
instead of, you know, showing me the expanded text so that I could see what's actually wrong with the generated variable declarations? Something like
: In function 'int kekw(int)':
:1:21: error: expected unqualified-id before 'int'
1 | #define W(a, b) b, int a
| ^~~
:2:18: note: in expansion of macro 'W'
2 | #define X(a, b) W(b, a)
| ^
:5:13: note: in expansion of macro 'X'
5 | int z = X(23, k) = x;
| ^
:5:-: note: the expanded source text is
| int z = 23, int k = x;
| ^~~
:6:16: error: 'k' was not declared in this scope
6 | return z + k;
|
perhaps? I understand that tracking the lines/columns inside the expanded text is highly non-trivial (although collapsing them all onto the position of the top-level macro is already just as non-trivial), but still. Show me what the source that you actually can't compile, not the three-steps removed precursor to it — I sure as hell can't expand macros in my head.
Also, what is this first error message about in the first place? Why the hell does it expect unqualified-id before "int"? If you put "int" after the unqualified-id, it still would be illegal; and an unqualified-id is not the only thing that can follow the comma in this context anyway.
During translation of source text to a C program, the source text goes through several phases. It turns raw bytes into preprocessor tokens, then preprocessor tokens get expanded into more preprocessor tokens and then preprocessor tokens get translated into C tokens, which are fed into the C parser. There is no “expanded text”, only expanded tokens. Generally this is implemented as a state machine that produces tokens on demand, so there is no expanded text. When GCC shows you that error message, it uses the recorded source location and looks it up in the original source file. This is trivial to do. Expanding just one line of the source file would either require re-invoking the preprocessor from the beginning or storing already consumed preprocessor tokens.
Obviously this is possible, but no one has gotten around to implementing this feature and it’s not clear you would want either solution: buffering preprocessor tokens in case you need to expand a line for an error message greatly increases memory usage and the vast majority of compilations are successful ones with no errors, slowing down the normal case. And re-invoking the preprocessor to show you one line on every error message makes error reporting slow.
> There is no “expanded text”, only expanded tokens.
If the compiler supports "-E", there absolutely is some equivalent of the expanded text, with (somewhat limited) whitespace info available: if you insert whitespace into between "b" and the comma in "b,", then "-E" invocation will dutifully show it. Yes, multiple spaces are collapsed into one, but their presence/absence is tracked already.
> Expanding just one line of the source file would either require re-invoking the preprocessor from the beginning or storing already consumed preprocessor tokens.
Yeah, keep the whole expansion of the latest top-level (not nested) macro. I believe some bytecode-like compression scheme (a replay of that state machine you mentioned) à la LZ would work fairly well, with minor additional memory necessary. Hell, scratch that: since #define/#undef are impossible inside a macro, you don't even need to remember the expansion of the macro, you simply need to keep the current macro definitions and remember what was the last macro you tried to expand — if your error happened inside its expansion, just re-expand again. Zero additional memory needed, since this information is already stored for the current way of error reporting — you can see in the current output that it remembers what macros it expanded and where, the whole path down to the offending token: at 1:21 "in expansion of macro 'W'" which was at 2:18 "in expansion of macro 'X'" which was at 5:13.
> And re-invoking the preprocessor to show you one line on every error message makes error reporting slow.
Eh, it's on the whole faster than making the programmer re-run with "-E" option manually.
> If the compiler supports "-E", there absolutely is some equivalent of the expanded text, with (somewhat limited) whitespace info available: if you insert whitespace into between "b" and the comma in "b,", then "-E" invocation will dutifully show it. Yes, multiple spaces are collapsed into one, but their presence/absence is tracked already.
Whitespace is significant in the preprocessor so of course it tracks whitespace. Whitespace isn’t dropped until phase 7 when pp-tokens are converted to C tokens.
As I said it’s not impossible, write the patch and see if GCC accepts it.
Also the position in the original source code is tracked.
In fact, this enhancement should be doable. Please file a bug. But the answer why something is not done in a C compiler is usually: Nobody did substantial investments on it in the last two decades. So if you want to see improvements, usually one has to submit a patch.
Terra is a native language that uses Lua for both meta-programming and scripting, it doesn't emit Lua VM bytecode. The actual statically-typed frontends (which are still alive) that I known of are Teal, Luon, Ravi, TypeScriptToLua and CSharp.lua.
Ah, the silly tradeoffs the ISAs expose us to. The CTZ/CLZ is fundamentally faster than floating point subtraction; but that doesn't mean that the CLZ/CTZ instruction will be faster than the FSUB. It could be but the vendors may as well decide to make it as slow as (or even slower than) FSUB.
reply