Re: What kind of Editor, IDE you are using and which one do you like for D language?
On 12/23/19 10:16 AM, Soulsbane wrote: On Sunday, 22 December 2019 at 17:20:51 UTC, BoQsc wrote: There are lots of editors/IDE's that support D language: https://wiki.dlang.org/Editors What kind of editor/IDE are you using and which one do you like the most? VSCode with this extension: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.vscode-dls I use this extension too
Re: What kind of Editor, IDE you are using and which one do you like for D language?
On Sunday, 22 December 2019 at 17:20:51 UTC, BoQsc wrote: There are lots of editors/IDE's that support D language: https://wiki.dlang.org/Editors What kind of editor/IDE are you using and which one do you like the most? VSCode with D extension
Re: What kind of Editor, IDE you are using and which one do you like for D language?
On Sunday, 22 December 2019 at 17:20:51 UTC, BoQsc wrote: There are lots of editors/IDE's that support D language: https://wiki.dlang.org/Editors What kind of editor/IDE are you using and which one do you like the most? VSCode with this extension: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.vscode-dls
Re: unicode characters are not printed correctly on the windows command line?
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. -Steve 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!
Re: What kind of Editor, IDE you are using and which one do you like for D language?
On Sunday, 22 December 2019 at 17:20:51 UTC, BoQsc wrote: There are lots of editors/IDE's that support D language: https://wiki.dlang.org/Editors What kind of editor/IDE are you using and which one do you like the most? I use Geany, but I don't know that there's any good argument for that beyond it being my personal preference. A plain text editor has always been sufficient for me. That's actually one of the things I find attractive about D.
Re: unicode characters are not printed correctly on the windows command line?
On 12/22/19 5:04 PM, Adam D. Ruppe wrote: On Sunday, 22 December 2019 at 18:41:16 UTC, Steven Schveighoffer wrote: Phobos doesn't call the wrong function, libc does. Phobos uses fwrite for output. There is allegedly a way to set fwrite to do the translations on MSVCRT: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode?view=vs-2019 Looks like you need to switch to "wprintf". I'm not sure, but I think we rely only on fwrite, for which there is no "w" equivalent. but trying it here it throws invalid parameter exception so idk. Not surprised ;) Here's a cool feature of Windows: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fwide?view=vs-2019 Basically does nothing, all parameters ignored (and yes, we use this function in Phobos, assuming it does something). But let me just say, the fact that there is some "mode" you have to set, like binary mode, that makes unicode work is unsettling. I hate libc streams... Regardless, I'm pretty well of the opinion that fwrite is the wrong thing to do anyway. fwrite writes bytes to a file, but we want to write strings to the console. There's other functions that do that. Preaching to the choir here. I wanted to rip out libc reliance a decade ago. There is the worry of mixing stuff from C and keeping the buffer consistent, but it could always just flush() before doing its thing too. Or maybe even merge the buffers, idk what the MS runtime supports for that. This is the crux. Some people gotta have their printf. And if you do different types of buffered streams, the result even from single-threaded output looks like garbage. The only solution is to wrap FILE *. And I do mean only. I looked into trying to hook the buffers. There's no reliable way without knowing all the implementation details. or maybe i'm missing something and _setmode is a viable solution. _setmode is on a file descriptor. That already is a red flag to me, as there are no file descriptors in the OS. Windows use handles. So this has some weird library "translation" happening underneath. Ugh. But whatever we do, passing the buck isn't solving anything. Windows has supported Unicode console output since NT 4.0 in 1996.. just have to call the right function, and whether it is Phobos calling it or druntime or the CRT, someone just needs to do it! Hey, you can always just call the function yourself! Just make an output stream that writes with the right function, and then you can use formattedWrite instead of writef. 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. -Steve
Re: unicode characters are not printed correctly on the windows command line?
On Sunday, 22 December 2019 at 18:41:16 UTC, Steven Schveighoffer wrote: Phobos doesn't call the wrong function, libc does. Phobos uses fwrite for output. There is allegedly a way to set fwrite to do the translations on MSVCRT: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode?view=vs-2019 but trying it here it throws invalid parameter exception so idk. Regardless, I'm pretty well of the opinion that fwrite is the wrong thing to do anyway. fwrite writes bytes to a file, but we want to write strings to the console. There's other functions that do that. There is the worry of mixing stuff from C and keeping the buffer consistent, but it could always just flush() before doing its thing too. Or maybe even merge the buffers, idk what the MS runtime supports for that. or maybe i'm missing something and _setmode is a viable solution. But whatever we do, passing the buck isn't solving anything. Windows has supported Unicode console output since NT 4.0 in 1996.. just have to call the right function, and whether it is Phobos calling it or druntime or the CRT, someone just needs to do it!
Re: D-ish way to work with strings?
On 12/22/19 9:15 AM, Robert M. Münch wrote: I want to do all the basics mutating things with strings: append, insert, replace What is the D-ish way to do that since string is aliased to immutable(char)[]? switch to using char[]. Unfortunately, there's a lot of code out there that accepts string instead of const(char)[], which is more usable. I think many people don't realize the purpose of the string type. It's meant to be something that is heap-allocated (or as a global), and NEVER goes out of scope. Many things are shoehorned into string which shouldn't be. Using arrays, using ~ operator, always copying, changing, combining my strings into a new one? Does it make sense to think about reducing GC pressure? It really depends on your use cases. strings are great precisely because they don't change. slicing makes huge sense there. I'm a bit lost in the possibilities and don't find any "that's the way to do it". Again, use char[] if you are going to be rearranging strings. And you have to take care not to cheat and cast to string. Always use idup if you need one. If you find Phobos functions that unnecessarily take string instead of const(char)[] please post to bugzilla. -Steve
Re: unicode characters are not printed correctly on the windows command line?
On 12/22/19 8:40 AM, Adam D. Ruppe wrote: On Sunday, 22 December 2019 at 06:25:42 UTC, rikki cattermole wrote: Not a bug. No, Phobos is *clearly* in the wrong here. There is a proper fix. Phobos doesn't call the wrong function, libc does. Phobos uses fwrite for output. http://dpldocs.info/this-week-in-d/Blog.Posted_2019_11_25.html#unicode You need to address that in DMC. I wonder, does MSVCRT have the same problem? -Steve
Re: D-ish way to work with strings?
Want to add I'm talking about unicode strings. Wouldn't it make sense to handle everything as UTF-32 so that iteration is simple because code-point = code-unit? And later on, convert to UTF-16 or UTF-8 on demand? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
What kind of Editor, IDE you are using and which one do you like for D language?
There are lots of editors/IDE's that support D language: https://wiki.dlang.org/Editors What kind of editor/IDE are you using and which one do you like the most?
D-ish way to work with strings?
I want to do all the basics mutating things with strings: append, insert, replace What is the D-ish way to do that since string is aliased to immutable(char)[]? Using arrays, using ~ operator, always copying, changing, combining my strings into a new one? Does it make sense to think about reducing GC pressure? I'm a bit lost in the possibilities and don't find any "that's the way to do it". -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: unicode characters are not printed correctly on the windows command line?
On Sunday, 22 December 2019 at 06:25:42 UTC, rikki cattermole wrote: Not a bug. No, Phobos is *clearly* in the wrong here. There is a proper fix. http://dpldocs.info/this-week-in-d/Blog.Posted_2019_11_25.html#unicode Use the correct WriteConsoleW api instead of the ancient ascii api. WriteConsoleW works without changing any settings. (on old versions of Windows, you may have to install fonts to display it, but new ones come with it all preinstalled).
Re: unicode characters are not printed correctly on the windows command line?
On Sunday, 22 December 2019 at 06:11:13 UTC, moth wrote: is there any function i can call or setting i can adjust to get D to do the same, or do i have to wait for something to be fixed in the language / compiler itself? It isn't the language/compiler per se, it is the library calling the wrong function. See the code in the link in my last email - if you call the Windows WriteConsoleW function directly it will do what you want. The rest of the surrounding code in the link is to handle conversions and pipes to files.
Re: unicode characters are not printed correctly on the windows command line?
On Sunday, 22 December 2019 at 06:25:42 UTC, rikki cattermole wrote: On 22/12/2019 7:11 PM, moth wrote: is there any function i can call or setting i can adjust to get D to do the same, or do i have to wait for something to be fixed in the language / compiler itself? Not a bug. This is a known issue on the Windows side for people new to developing natively for it. Yes, and it's not just D programs. And setting the code page isn't always perfect, as it matters which font cmd is configured to use. Google for "windows command prompt unicode output". MS has updated the command prompt to support Unicode, but I don't know how to use it: https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/ If you're on Windows 10, there's also Windows Terminal, which was released on the app store in June: https://devblogs.microsoft.com/commandline/windows-terminal-preview-v0-7-release/
