unicode characters are not printed correctly on the windows command line?

[Steven Schveighoffer]

On 12/22/19 11:53 PM, Symphony wrote:
> On Sunday, 22 December 2019 at 22:47:43 UTC, Steven Schveighoffer wrote:
>> To fix Phobos, we just(!) need to remove libc as the underlying stream 
>> implementation.
>>
>> I had at one point agreement from Walter to make a 
>> "backwards-compatible-ish" mechanism for file/streams. But it's not 
>> pretty, and was convoluted. At the time, I was struggling getting what 
>> would become iopipe to be usable on its own, and I eventually quit 
>> worrying about that aspect of it.
>>
>> We have the basic building blocks with 
>> https://github.com/MartinNowak/io and 
>> https://github.com/schveiguy/iopipe. It would be cool to get this into 
>> Phobos, but it's a lot of work.
>>
>> I bet Rust just skips libc altogether.
>>
> I don't have the ingenuity, intelligence, nor experience that many of 
> you possess, but I have *a lot* of time on my hands for something like 
> this. I assume I should start with std.stdio's source code and the 
> aforementioned projects' source code, but some guidance on this would be 
> very helpful, if not needed. D has been quite useful to me since I 
> stumbled upon it, and I think it's time to give back in some way. (I'd 
> do it financially, but I'm poor, haha) Anyway, if anybody wants to take 
> me up on this offer, just let me know!

I really appreciate the enthusiasm here, but at the risk of being 
cynical, I see little chance that this gets accepted. Before you spend 
any time on actual code, a DIP is going to be required, as this would be 
a huge change to the language. I'm sure you have a lot of time, but I 
don't want you to waste it on something that is likely to be rejected.

If you still want to proceed, even at the risk of doing a lot of work 
for nothing (or at least, a lot of work that ends up being just on 
code.dlang.org instead of Phobos), I can tell you what my plan was:

1. std.stdio.File was going to be set up to source from either an 
iopipe-based io subsystem, or a FILE *.

2. The standard handles would be open with the default C FILE * standard 
handles as the source/target.

3. Upon using any "d-like" features on a File that is sourced from a 
FILE * (i.e. byline), the File would be switched to a newly-created 
iopipe-based source. The theory is here, that once you do something like 
this, you commit to using D on that, and I'd much rather use a higher 
performing subsystem (iopipe beats Phobos right now by 2x performance). 
This only counts for things that make the File unusable on its own 
anyway. So writefln and writeln would NOT switch the source, neither 
would lockingTextReader/Writer.

4. Any new File that is opened using any constructor other than passing 
in a FILE * will be opened with an iopipe source.

5. The iopipe and io subsystems can be used directly instead of with 
File, as a lot of times you don't need that overhead.

Let me know if you decide to do this, I can guide you.

-Steve