with 4G/5G home internet, there's no real point anymore.
17 karma · joined March 18, 2015
with 4G/5G home internet, there's no real point anymore.
Parents students and teachers treated me like shit throughout elementary school, went to a new school and decided I wasn't gonna take it anymore.
Started misbehaving and getting suspended literally all the time, had over 400 disciplinary actions on my school recorded, got expelled from a few schools then expelled from the whole district, as in they just wouldn't let me go to that high school at all...
Turned myself around after choking my sister when I was 15 and damn near got arrested for it.
As in, I was sitting in the back of a cop car, not handcuffed but they patted me down, bawling my eyes out.
Thankfully my sister didn't say a word to the cop and that's when I decided I had to change.
First Google is gonna run Fuchsia on Linux, then linux will be removed entirely.
that's what this laying the groundwork for.
I just called up ASUS and shipped the board to them, I paid the shipping cost and they reprogrammed the BIOS for free, besides shipping.
> - the C pre-processor knows nothing about lists that can be expanded multiple times;
I'm actually working on both features as Clang extensions.
#repeat, a preprocessor directive to loop, can be combined with _Pragma(push_macro/pop_macro) to create lists by redefining a macro.
and currently #increment, though I think I want to expand on this so that other macros can be redefined more easily to create lists via push/pop macro.
The reason push_macro/pop_macro pragmas can't work, is the macro has to be undefined and redefined, and the value then pushed onto a stack in the compiler.
and you can't redefine a macro in the body of another macro directly.
so I've been thinking about maybe a _Pragma(redefine_macro(MacroToRedefine, NewValueForRedefinedMacro))
but I don't want it to be limited to the _Pragma area of the compiler, I want it to be eventually standardized.
I've been talking to a friend at WG14 who suggested making it a "Preprocessor Expression, like `__has_c_attribute` and `defined()`
So that's the area I've been working on recently for the Increment/Redefine PE lately.
They bought Android in 2005, Youtube in 2004? and all of their other, non-search successes.
You only need to pay for it if you distribute your app on the app store.
This seems like just another gimmick to push D tbh.
modern syntax is:
char *Combine(char *S, char *T) {
...
}
which means the Combine function returns a string (char pointer), and takes as arguments two strings, S and T.Remote: It'd be nice, but not a must have.
Willing to relocate: No, I just moved here from Michigan a month ago.
Technologies: C, C++, Shell Scripting (Bash), Probably other things I've forgotten about.
So I don't think C has a very high learning curve, C++ on the other hand...
How likely would the standard be to accept a proposal to add compile time reflection to the preprocessor, or even adopt C++'s constexpr?
My use case is creating a global array in a header from static compound literals in multiple source files at compile time, and outside of some crazy clang-tblgen type solution, or very platform specific linker hacks, it's completely unsupported by C.
they're proposing to add u8 as a character constant prefix.
Is the Axolotl's genome really 42.5 times larger than ours?
Kinda? It isn't limited to just the byte order tho, but I can see it.
> Why integrate it into the code unit if you're only going to have one of them?
There would be multiple code units, just 1 of the mini headers/BOM.
With that comment I was trying to contrast it to UTF-8 which has those 2 leading bits of the continuation code units set to `0b10`, it wouldn't have that.
What do you mean by variable width? the 4 bit header would be limited to the first code unit, the following ones would just be pure codepoint values.
and that's a good point, I as picturing it as the top 4 bits that describe the format, so the header's byte order would be field, but the actual codepoint value would be encoded with whatever byte and bit order the header indicated.
yup and yup.
UTF-8 is capped at 21 bits, theoretically it can support up to 6, but it's not allowed to because of UTF-16.
This format would allow 28 bits to be encoded as 8, 16, and 32 bit code units.
There would be no surrogate pair nonsense, simply write all the non-leading-zero bits into as many code units you need as well as the 4 bit header, and you're good.
I'm not saying it'll ever happen, I know it won't, but if we could go back in time...
you can fit all of that information into 4 bits when you just care about minimizing the size of that mini header.
I know that, because I got bored and made up a quick proposal on it, not that I expect anyone else to even look at it.
have it use Unicode line endings (or, if Unicode has to be recreated, do IT right, and have it use 28 bits for codepoints and 2 bits describing the format).
the packet's themselves are only 1.5kb.