151–160 of 196 posts
-- Those who don't understand Unix are condemned to reinvent it, poorly. Henry Spencer
Sometimes people just insist on using stuff that sucks.
Earlier quoted context omitted.
I don't see anything wrong with what you're saying, but I still don't get how it explains the original comment I replied to [1]: > I'm not at all convinced that 2^21 codepoints will be enough, so someday it'd be nice to be able to get past UTF-16 and move to UTF-8 UTF-16 currently uses up to 2 16-bit code units per code point, whereas UTF-8 uses up to 4 8-bit code units per code point, and the latter wastes more bits…
If I had intended to explain that, I wouldn't be replying to your comment about your not working out the bits with an explanation that works out the bits for you, and shows that it really is capable of encoding all 17 planes even though surrogate pairs have only 20 bits. And as you can see, if you do work out the bits, you find that cryptonector is wrong, since UTF-8 (as it has been standardized from almost the start…
With regards to the comment then: the range downshifting you mentioned is merely a step in the encoding process though -- the code point is still whatever it was. If you read parent comment, it had claimed that, in a surrogate pair, each of the 2 code units encodes 10 bits of the code point... but that would be missing 1 bit when the code points need 21 bits to be represented. That's all I was saying there. The extra bit indicating that it's in fact a surrogate pair isn't some kind of implicit dummy bit that you can pretend isn't encoding anything -- if it wasn't there then clearly it wouldn't be encoding the code point for a surrogate pair anymore.
Earlier quoted context omitted.
It's already there: https://docs.microsoft.com/en-us/windows/desktop/ProcThread/... You can set various limits, though I haven't seen functions to stop/resume a job.
You can suspend and resume threads, so if you model your jobs with processes that could be used for that, I guess.
Earlier quoted context omitted.
The ConPTY is not just about compatibility with nix. It's about proper remoting of consoles. Unix got that right / Windows got that wrong, and now Windows will finally get it right too -- that it helps nix compat seems like a happy accident (though obviously they want that too, so not so accidental.
Right. For a long time, the MS remoting philosophy was that applications should be remoted, not text streams. The stance goes all the way back to DCOM. That's why PowerShell remoting looks more like a local PowerShell executing commands on a remote machine than it looks like you just connecting to a PowerShell running elsewhere. The difference is important, since in the traditional MS model, each program that wants t…
Earlier quoted context omitted.
I want a pipe2(2) flag or an fcntl or something that lets me signal "the other end of this pipe understands ANSI escapes"
First of all you have to define "ANSI escape". Hints: * You have the wrong country, on the wrong continent. * It's not as simple in reality as your first answer will be. (-:
I always liked the Console API where you can set the color of the text without actually changing the text that is written to Stdout. No issues when piping the output somewhere else. No need to check whether the output is getting piped.
That'll work just the same as it always has :) Existing commandline applications won't be affected by this feature, but it will open the doors for an entirely new class of applications.
Earlier quoted context omitted.
26 years ago.
Which is : https://en.wikipedia.org/wiki/Windows_3.1x
Earlier quoted context omitted.
> Why would you want to do that? Use (RPC | shared memory | some other IPC mechanism). Yes, structured data exchange is the correct answer. When I have the opportunity to code something from scratch, this is the route I take.
> When I have the opportunity to code something from scratch But how often does that happen, outside of toy systems and support utilities?
Earlier quoted context omitted.
Windows does have signals! It just splits them into a few facilities. POSIX "synchronous" signals correspond to SEH exceptions and can be handled roughly the same way --- except that signals have process global handlers and Windows has thread-local ones, because the glibc people are sticks in the mud and are hostile to any attempt to make signals suck less. For asynchronous signals, like SIGINT, Windows create a new…
Spawning a new thread to handle a signal is much better than preemption: you then have no concerns about async-signal-safety that aren't plain old thread-safety concerns. I'd much rather have thread-safety constraints than async-signal-safety constraints.
Earlier quoted context omitted.
Where are you getting this information though? I haven't worked out the bits myself yet but Wikipedia's first sentence itself says UTF-16 can encode all 1,112,064 valid code points of Unicode, which is already more than 2^(10+10) = 1,048,576.
Unicode code point space: Was 16-bit (0000 to FFFF), then 32-bit (00000000 to FFFFFFFF), and is now 21-bit (00000000 to 0010FFFF) UTF-16: Encodes the entire 21-bit range, encoding most of the first 0000 to FFFF range as-is, and using surrogate pairs in that range to encode 00010000 to 0010FFFF. The latter range is shifted to 00000000 to 000FFFFF before encoding, which can be encoded in the 20 bits that surrogate pair…
Not exactly. A conforming decoder MUST reject them.
MySQL’s problem is that, by default, it can’t even handle all valid code points.