Re: Best way to read/write Chinese (GBK/GB18030) files?
On Friday, 10 March 2023 at 06:19:38 UTC, zjh wrote: `D language` is too unfriendly for Chinese users! You can't even write `gbk` files.
Re: Best way to read/write Chinese (GBK/GB18030) files?
On Friday, 10 March 2023 at 02:48:43 UTC, John Xu wrote:
```d
module chinese;
import std.stdio : writeln;
import std.conv;
import std.windows.charset;
int main(string[] argv)
{
auto s1 = "中文";//utf8 字符串
writeln("word:"~ s1); //乱的
writeln("word:" ~ to!string(toMBSz(text(s1; //转后就正常了
writeln("Hello D-World!");
return 0;
}
```
How to expand wildchar under dos ?
Under dos, how to get wildchar matched file names? PS E:> dmd a.d PS E:> .\a.exe a.* args=["a.exe", "a.*"] d-glob doesn't function well under windows dos either.
Re: Best way to read/write Chinese (GBK/GB18030) files?
I found this: https://github.com/meatatt/exCode/blob/master/source/excode/package.d There is mention of unicode/GBK conversion, maybe it could be helpful Thanks for quick answers. Now I found I can read both UTF8 and UTF-16LE chinese file: string txt = std.file.read(chineseFile).to!string; and write to UTF8 file: std.file.write(utf8ChineseFile, txt); But still need figure out how to read/write GBK directly.
Re: Can nice D code get a bit slow?
On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote: btw. As far as I can tell (using the example in the link below), compiled D (using the ldc compiler with -O3) will optimise the call just fine. However, not including the 'final' keyword would not mean the end of the world ;-) https://godbolt.org/z/nW5s3z1Tc
Re: dub.sdl bindbc-glfw is returning a deprecation warming. So what do I do now?
On Thursday, 9 March 2023 at 06:36:18 UTC, IchorDev wrote: On Thursday, 9 March 2023 at 00:21:02 UTC, WhatMeWorry wrote: [...] Sorry about that. Try updating to bindbc-glfw 1.0.2, should be fixed now. If you see any other deprecation warnings from BindBC bindings you can silence them with `-d` until they're updated. No problem :) Thanks!
Re: help: Unresolvable dependencies to package openssl
On Thursday, 9 March 2023 at 01:22:08 UTC, Steven Schveighoffer wrote: This is a known limitation -- dub builds the selections file based on *all* configurations in the file. If you have conflicting ones, it will not know what to pick. However, if you manually construct the selections file, then it will work. Thanks, it worked. See https://github.com/dlang/dub/issues/1217 -Steve
Re: DlangUI Layout Justification
On Thursday, 9 March 2023 at 14:39:06 UTC, ryuukk_ wrote: On Thursday, 9 March 2023 at 10:11:04 UTC, Ron Tarrant wrote: Has anyone else been using D to develop for Android? If so, have you documented your process/GUI toolkit choices and would you be willing to share with me? Adam has something for Android: https://github.com/adamdruppe/d_android Many thanks, ryuukk. I'll check it out.
Re: DlangUI Layout Justification
On Thursday, 9 March 2023 at 10:11:04 UTC, Ron Tarrant wrote: Has anyone else been using D to develop for Android? If so, have you documented your process/GUI toolkit choices and would you be willing to share with me? Adam has something for Android: https://github.com/adamdruppe/d_android
Re: DlangUI Layout Justification
On Thursday, 9 March 2023 at 10:51:31 UTC, Ron Tarrant wrote: Another question... I found LinkButton in the API, but I don't see how/where to give it a URL to go to. Anyone know? Okay, so far I've got Platform.openURL(), but no idea how to use it. Pass it a string, yes, I got that part, but how do I attach it as an action to a LinkButton? Or is attaching actions not the way it's done? I'm off to find out what's written about actions in dlangUI.
Re: Can nice D code get a bit slow?
On Wednesday, 8 March 2023 at 12:46:53 UTC, Hipreme wrote: On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote: Hi, sorry for the broad and vague question. I have read in some reddit post about benchmarks, that some code didn't use the final keyword on methods in a sense that final would make it faster, I believe. [...] Don't bother with it. This kind of optimization is done when compiling with -O, No they are not, simple example : https://godbolt.org/z/xfPqnWrrv Obviously in a library `test` might be called with a derived so `v1()` target address must be read in the vtbl of the argument. and I really doubt about your bottleneck being that you're calling a virtual call. That is more true. vcalls dont add complexity. Wait when you actually need to optimize before making your code ugly.
Re: DlangUI Layout Justification
Another question... I found LinkButton in the API, but I don't see how/where to give it a URL to go to. Anyone know?
Re: DlangUI Layout Justification
On Thursday, 9 March 2023 at 10:11:04 UTC, Ron Tarrant wrote: Is there a way to right-justify widgets in a DlangUI Layout? Found it! (In Example 1 [duh]). Still hoping to hear back from someone about the other question.
Re: Can nice D code get a bit slow?
On Thursday, 9 March 2023 at 10:05:35 UTC, FozzieBear wrote: .. But that assumes you even know how long 7 nanoseconds are .. cause I don't. Well, it turns out, that light takes about a nanosecond to travel 1 foot. So that means, the performance impact from using a virutal call, would be equivalent to the amount of time light takes to travel 7 feet. I'm sure there are applications out there that might need to take this into account. But for most, its trivial and irrelvant, and the programmer would benefit from focusing on more important things.
DlangUI Layout Justification
Hi all, It's been a while since I've been on this forum. Hope everyone is doing well and have survived the pandemic. Anyway, a question... Is there a way to right-justify widgets in a DlangUI Layout? I'm asking because I've spent the last six months learning to build Android apps with the Godot Game Engine, but frankly, it's cumbersome and I really miss D. So, I'm looking into D-language GUI toolkits that will allow me to make the transition. And that leads to another question... Has anyone else been using D to develop for Android? If so, have you documented your process/GUI toolkit choices and would you be willing to share with me? With all that said, y'all take care and have a nice day. :)
Re: Can nice D code get a bit slow?
On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote: Hi, sorry for the broad and vague question. I have read in some reddit post about benchmarks, that some code didn't use the final keyword on methods in a sense that final would make it faster, I believe. I thought, without any D knowledge, it could be that with shorter code I might create virtual calls by accident. It might in some rare case have an impact on performance, but it might - on the good side - be the optimizer of one of the three compilers that puts that handling of maybe-virtual calls away or whatever might happen. So, having no clue about D (just bought some books), I wanted to ask if nice looking code can become slow, in general. In the mentioned case it's just that I like the packaging of functions into some sort of scope (OOP) versus the flat C and Go stuff. I like OOP for this reason, but now I'm unsure whether I might stay out of creating classes at all. I do like to write 'in' and 'ref' keywords at their places, for maybe creating some little speed benefits and safety, but the 'final' keyword I then might write because I opted in into OOP looks, for just the visual reason. Uh, hope you understand my vague question, sorry about that. I found D to be the right place because it's not missing any essential feature I know of. Kind regards The whole point of OO programming, made convenient by the class type, is to enable you to more easily work with abstractions that relate to your problem domain, rather than abstractions related to the processing of your code at the machine level (cpu, memory, cache, registers... etc.). This is, in essence, the difference between C like programming, and OOP. Now if 7 nanoseconds (more or less) pose a signficant performance issue for the solution you're developing, then OOP probably isn't what you're looking for anyway. Having said that though, any info you can provide to the compiler so that it can (hopefully) use that information at compile time and insert direct calls instead of virtual calls, may be worthwhile. But that assumes you even know how long 7 nanoseconds are .. cause I don't.
