Re: execute bash?
On Sunday, 10 April 2016 at 00:47:28 UTC, Puming wrote: 3. when hiting 'vim a.file' on the command, things go messy. Have you got these interactive commands work in dexpect? It is surely capturing exactly what vim sends to a terminal, which is primarily a series of control sequences to draw the screen, move the cursor, color it, etc. You might want to watch for those and just forward them directly to the user terminal... but this is getting kinda wild 1. Fully proxy for a bash shell. 2. Result data are separated for each command. So I can easily search for hitorical sent commands or results. What you probably want to do is just send one command at a time to the bash process and handle the rest yourself. Or just forget bash and write your own shell.
Re: Why do my stack traces look like this? How can I get more informative ones?
On Sunday, 10 April 2016 at 00:48:23 UTC, pineapple wrote: How can I fix this, and get something human-readable? Oh, answered my own question. Appending the -g flag to dmd options makes the stack trace much prettier.
Why do my stack traces look like this? How can I get more informative ones?
I'm getting a RangeError and the stack trace is being spectacularly unhelpful in debugging the problem, because it looks like this: core.exception.RangeError@E:\Dropbox\Projects\d\lib\wip_ansi_2.d(78): Range violation 0x0040A240 0x00402E37 0x00402B5E 0x00402985 0x00402F29 0x0040C3A3 0x0040C367 0x0040C268 0x0040965F 0x758533AA in BaseThreadInitThunk 0x77699F72 in RtlInitializeExceptionChain 0x77699F45 in RtlInitializeExceptionChain How can I fix this, and get something human-readable?
Re: execute bash?
On Saturday, 9 April 2016 at 08:56:17 UTC, wobbles wrote: On Friday, 8 April 2016 at 23:06:06 UTC, Puming wrote: On Friday, 8 April 2016 at 18:23:32 UTC, wobbles wrote: On Friday, 8 April 2016 at 16:07:13 UTC, Adam D. Ruppe wrote: On Friday, 8 April 2016 at 15:20:09 UTC, Puming wrote: I tried with signal, but didn't catch SIGTTOU, it seems that spawnProcess with `bash -i -c` will signal with SIGTTIN. Oh, surely because it wants to be interactive and is thus waiting for user input from the terminal.. You might need to rig up a pseudo terminal that the bash can talk to. That's getting to be a pain though. You could run it through dexpect to get the effect of a pseudo terminal. https://github.com/grogancolin/dexpect Looked in the code, it is exacly what I need! Thanks. Also it has spawnInPty Cool. Any questions on using it let me know. I'm all for a bit of feedback also! I tried dexpect, now it works for the bash emulation! But there are still some issues: 1. Spawn's data is a string, so it stores ALL data, but Expect class does not have a clear() method, so the data piles up and takes memory. 2. There seems to be a visible lag for each send->read cycle. I haven't look in the details to find where, but it feels not as smooth as ssh does. 3. when hiting 'vim a.file' on the command, things go messy. Have you got these interactive commands work in dexpect? My wish list for the Expect class ( or design a separate class, like BashProxy ): 1. Fully proxy for a bash shell. 2. Result data are separated for each command. So I can easily search for hitorical sent commands or results. But for now it works fine for my needs. I'll try to improve it when I get major parts of my repl lib done.
Re: Practical difference between a struct with const members and with mutable members?
On Saturday, April 09, 2016 16:07:36 pineapple via Digitalmars-d-learn wrote:
> I'm mainly coming from languages that haven't got structs, let
> alone the kind of differentiation D offers between
> mutable/immutable/const/etc variables, so I'm still trying to
> work out just when to use each - What's different between these
> two examples, practically speaking? When would you use one over
> the other?
>
> struct thing1{
> const int x, y;
> }
>
> struct thing2{
> int x, y;
> }
>
> Thanks!
You'll be much happier if you don't make the members of a struct const or
immutable. When they're const or immutable, you cannot mutate them, and you
cannot mutate the struct as a whole (though other members can still be
mutated). Not being able to mutate the const members is presumably what you
want, but not being able to mutate the struct as a whole can be very
annoying. For instance, if you have
struct S
{
string foo;
const int bar;
}
auto s = S("hello", 42);
s.foo = "world";
s.bar = 77; // does not compile
s = S("dlang", 99); // does not compile
Presumably, you don't want bar to be able to change (which is why you made
it const), so the first error is fine, but the second could be a big
problem. By making a portion of the struct const, you can't assign to it
anymore or do anything that would mutate it as a whole. You can just mutate
its mutable members directly. Contrast this with
struct S
{
string foo;
int bar;
}
auto s = S("hello", 42);
s.foo = "world";
s.bar = 77; // compiles
s = S("dlang", 99); // compiles
const t = S("str", 12);
t.foo = "ing"; // does not compile
t.bar = 7; // does not compile
t = S("duck", 2); // does not compile
This version of S can still be const if you want it to be, but it doesn't
have to be - though obviously, bar can now be mutated if the struct as a
whole is not const. The way to fix that is to provide a getter but not a
setter. eg.
struct S
{
public:
@property string foo() const { return _foo; }
@property void foo(string value) { _foo = value; }
@property int bar() const { return _bar; }
private:
string _foo;
int _bar;
}
auto s = S("hello", 42);
s.foo = "world";
s.bar = 77; // does not compile
s = S("dlang", 99); // compiles
const t = S("str", 12);
t.foo = "ing"; // does not compile
t.bar = 7; // does not compile
t = S("duck", 2); // does not compile
Because foo provides both a getter and a setter, it can be mutated as
before, but because bar only provides a setter, it can't be mutated even
when the struct is mutable - but you can still replace its value when you
assign a value to the entire struct. And of course, if an instance of the
struct is marked as const, then you can't mutate any of it. So, this
approach gives you full flexibility.
Now, having const or immutable members for classes isn't generally a
problem, beacause they're on the heap, and you don't normally assign a new
value to a class (rather, you just assign a new value to a reference to that
object so that the reference refers to a different object, but the previous
object wasn't actually mutated). e.g.
class C
{
this(string f, int b)
{
foo = f;
bar = b;
}
string foo;
const int bar;
}
auto c = new C("hello", 42);
c.foo = "world";
c.bar = 77; // does not compile
c = new C("dlang", 99); // compiles
const d = new C("str", 12);
d.foo = "ing"; // does not compile
d.bar = 7; // does not compile
d = new C("duck", 2); // does not compile
So, having const members for classes usually works well, but because structs
normally live on the stack rather than having that layer of indirection,
giving them const members does tend to get in the way.
- Jonathan M Davis
Re: Fiber and Thread Communication
On 04/09/2016 07:45 AM, Nordlöw wrote: > On Friday, 8 April 2016 at 10:51:49 UTC, Nordlöw wrote: > AFAICT, it is not clear what are the limitations of the current > std.concurrency and, from what. An illustrating example on task-based > parallellism (such as the ones in jin.go) should partly alleviate this > problem. I don't know how much this helps but I was able to write an example that seems to work (elsewhere in this thread): http://forum.dlang.org/post/nec62k$26v7$1...@digitalmars.com Ali
Re: Fiber and Thread Communication
On 04/08/2016 02:42 PM, Dicebot wrote:
>> Thanks Dicebot. I don't think the included
>> std.concurrency.FiberScheduler has support for message passing because
>> FiberScheduler.spawn does not return a Tid. If so, I don't see how
>> it's possible to send messages between fibers.
>>
>> Ali
>
> Looks like a (funny) oversight.
Sorry, I misled you. :)
> Note that you get it for get fiber via
>
https://github.com/D-Programming-Language/phobos/blob/master/std/concurrency.d#L1337
> (and FiberScheduler specifically extends Fiber to add ThreadInfo to it)
> but there is no clear way to pass that info to spawn host. I have a
> feeling that if that code is patched to simply provide Tid, message
> passing will just magically work. Needs to be checked though.
It turns out, instead of calling scheduler.spawn() directly, the program
sets the __gshared 'scheduler' variable first and then calls spawn() as
usual, which does return that fiber's Tid:
import std.stdio;
import std.concurrency;
import std.range;
import std.algorithm;
struct Done {
}
void workerTask(int id) {
writefln("workerTask %s started", id);
bool done = false;
while (!done) {
receive(
(int message) {
writefln("workerTask %s received %s", id, message);
ownerTid.send(message * id);
},
(Done message) {
writefln("workerTask %s received Done", id);
done = true;
});
// Seems not to be needed:
// scheduler.yield();
}
writefln("workerTask %s exiting", id);
}
void mainTask() {
enum workerCount = 5;
enum loopCount = 3;
writeln("mainTask started");
auto workers = iota(workerCount)
.map!(id => spawn(, id))
.array;
foreach (i; 0 .. loopCount) {
foreach (id, worker; workers) {
worker.send(i);
auto response = receiveOnly!int();
assert(response == i * id);
writefln("mainTask received %s", response);
}
}
writeln("mainTask sending Done messages");
foreach (worker; workers) {
worker.send(Done());
}
writeln("mainTask exiting");
}
void main() {
scheduler = new FiberScheduler;
scheduler.start({
mainTask();
});
}
Ali
Re: Stupid question about AA. The following code works but I don't undrstand why?!
On Saturday, 9 April 2016 at 19:31:31 UTC, Uranuz wrote: I think that we need to add warning about such case in documentation section: https://dlang.org/spec/hash-map.html#construction_and_ref_semantic in order to prevent this kind of mistakes in code. Isn't that exactly what the section you linked does?
Re: Stupid question about AA. The following code works but I don't undrstand why?!
On Saturday, 9 April 2016 at 19:25:32 UTC, Uranuz wrote:
Another observation is illustrated with the foloving code:
http://dpaste.dzfl.pl/8d68fd5922b7
Because AA and arrays are not created before they were assigned
some value it leads to inconsistency in behavior. And will
produce unexpected and hidden bugs that is not good. It's not
very good side of D's array and AA. But classes could be also
affected by this *feature* (or bug, as you wish). So we must
always construct reference semantics types before passing them
to functions that will modify it. For classes it's obvious but
for AA and dynamic arrays is not.
The inconsistency is only there with associative arrays, where
adding a key may or may not affect other views of the AA,
depending on if the AA was empty before or not.
In code:
int[int] aa1;
...
int[int] aa2 = aa1;
aa2[0] = 0; /* may or may not affect aa1 */
With dynamic arrays, appending does never affect other views, no
matter if the array was empty or not.
In code:
int[] a1;
...
int[] a2 = a1;
a2 ~= 1; /* never affects a1 */
Dynamic arrays do have a similar oddity, but it doesn't depend on
empty/non-empty. It depends on the capacity. When you append to a
dynamic array that has no capacity left, a new copy of the data
is made. The dynamic array then becomes independent of other ones
with which it used to share data.
In code:
int[] a1 = [0];
...
int[] a2 = a1;
a2 ~= 1; /* never affects a1 */
a2[0] = 1; /* may or may not affect a1 */
With class references I can't see any inconsistency. When you're
given a null reference, all you can do is construct an object
there, which never affects other copies of the reference. And
when you mutate through a non-null reference, that always affects
other copies of the references, of course.
In code:
class C {int x = 0;}
C c1;
...
C c2 = c1;
c2 = new C; /* never affects c1 */
c1 = c2;
c2.x = 1; /* obviously affects c1 */
Another solution is to pass reference types by *ref*. So you
will not have such bugs in implementation
Yup, if you mean to affect the passed variable, ref is the way to
go. And if you don't mean to affect the passed variable, you
should probably mark the parameters const, or at least the
reference part of the parameters (e.g. const(int)[]).
Re: Stupid question about AA. The following code works but I don't undrstand why?!
On Saturday, 9 April 2016 at 19:25:32 UTC, Uranuz wrote: On Saturday, 9 April 2016 at 18:27:11 UTC, ag0aep6g wrote: [...] Another observation is illustrated with the foloving code: http://dpaste.dzfl.pl/8d68fd5922b7 Because AA and arrays are not created before they were assigned some value it leads to inconsistency in behavior. And will produce unexpected and hidden bugs that is not good. It's not very good side of D's array and AA. But classes could be also affected by this *feature* (or bug, as you wish). So we must always construct reference semantics types before passing them to functions that will modify it. For classes it's obvious but for AA and dynamic arrays is not. Another solution is to pass reference types by *ref*. So you will not have such bugs in implementation I think that we need to add warning about such case in documentation section: https://dlang.org/spec/hash-map.html#construction_and_ref_semantic in order to prevent this kind of mistakes in code.
Re: Stupid question about AA. The following code works but I don't undrstand why?!
On Saturday, 9 April 2016 at 18:27:11 UTC, ag0aep6g wrote: On Saturday, 9 April 2016 at 18:06:52 UTC, Uranuz wrote: Thanks. It's clear now. AA holds not `array struct` itself inside, but pointer to it. How the array is stored in the AA doesn't matter, as far as I can see. The point is that you obtain a pointer to the array struct in the AA, not a copy. If you had tried it like the following, mapElem would be a copy of the array struct in the AA, and the append would not affect mapka["item"]: string[] mapElem = "item" in mapka ? mapka["item"] : (mapka["item"] = []); mapElem ~= ["dog", "cat", "horse", "penguin", "fish", "frog"]; So reallocation affects ptr to allocated memory but not pointer to `array struct`. I think that's it. Correct. Another observation is illustrated with the foloving code: http://dpaste.dzfl.pl/8d68fd5922b7 Because AA and arrays are not created before they were assigned some value it leads to inconsistency in behavior. And will produce unexpected and hidden bugs that is not good. It's not very good side of D's array and AA. But classes could be also affected by this *feature* (or bug, as you wish). So we must always construct reference semantics types before passing them to functions that will modify it. For classes it's obvious but for AA and dynamic arrays is not. Another solution is to pass reference types by *ref*. So you will not have such bugs in implementation
Re: Stupid question about AA. The following code works but I don't undrstand why?!
On Saturday, 9 April 2016 at 18:06:52 UTC, Uranuz wrote: Thanks. It's clear now. AA holds not `array struct` itself inside, but pointer to it. How the array is stored in the AA doesn't matter, as far as I can see. The point is that you obtain a pointer to the array struct in the AA, not a copy. If you had tried it like the following, mapElem would be a copy of the array struct in the AA, and the append would not affect mapka["item"]: string[] mapElem = "item" in mapka ? mapka["item"] : (mapka["item"] = []); mapElem ~= ["dog", "cat", "horse", "penguin", "fish", "frog"]; So reallocation affects ptr to allocated memory but not pointer to `array struct`. I think that's it. Correct.
Re: Stupid question about AA. The following code works but I don't undrstand why?!
On Saturday, 9 April 2016 at 16:44:06 UTC, ag0aep6g wrote:
On 09.04.2016 18:13, Uranuz wrote:
http://dpaste.dzfl.pl/523781df67ab
For reference, the code:
import std.stdio;
void main()
{
string[][string] mapka;
string[]* mapElem = "item" in mapka; //Checking if I have item
if( !mapElem )
mapElem = &( mapka["item"] = [] ); //Creating empty element
inside map
writeln( (*mapElem).capacity );
//Appending should reallocate, so pointer to array should
change
*mapElem ~= ["dog", "cat", "horse", "penguin", "fish", "frog"];
//But AA still somehow knows the right pointer
writeln(mapka);
//It works, but I dont understand why?
}
mapElem is not a pointer to the elements of the array. It's a
pointer to the dynamic array structure which holds the pointer
to the data and the length. That means, the reallocation
doesn't change mapElem. It changes (*mapElem).ptr.
Thanks. It's clear now. AA holds not `array struct` itself
inside, but pointer to it. So reallocation affects ptr to
allocated memory but not pointer to `array struct`. I think
that's it.
Re: Stupid question about AA. The following code works but I don't undrstand why?!
On 09.04.2016 18:13, Uranuz wrote:
http://dpaste.dzfl.pl/523781df67ab
For reference, the code:
import std.stdio;
void main()
{
string[][string] mapka;
string[]* mapElem = "item" in mapka; //Checking if I have item
if( !mapElem )
mapElem = &( mapka["item"] = [] ); //Creating empty element
inside map
writeln( (*mapElem).capacity );
//Appending should reallocate, so pointer to array should change
*mapElem ~= ["dog", "cat", "horse", "penguin", "fish", "frog"];
//But AA still somehow knows the right pointer
writeln(mapka);
//It works, but I dont understand why?
}
mapElem is not a pointer to the elements of the array. It's a pointer to
the dynamic array structure which holds the pointer to the data and the
length. That means, the reallocation doesn't change mapElem. It changes
(*mapElem).ptr.
Re: Practical difference between a struct with const members and with mutable members?
On 09.04.2016 18:07, pineapple wrote:
What's different between these two examples, practically speaking? When
would you use one over the other?
struct thing1{
const int x, y;
}
struct thing2{
int x, y;
}
In this case, const is practically the same as immutable. But immutable
is the stricter qualifier. It's more self-documenting, and it may be
simpler to utilize for the compiler in terms of optimizations. So I'd
use immutable instead of const here. Differences between const and
immutable manifest with indirections (pointers, arrays, classes, ...).
The effect of const (or immutable) in thing1 is simple: you can't mutate
its x or y after construction. Whereas thing2 allows mutation of its x
and y.
In code:
thing1 t1;
t1 = thing1(1, 2); /* doesn't compile; the fields of t1 are immutable */
thing2 t2;
t2 = thing2(1, 2); /* compiles */
You can do the same with thing2 on a per-object basis:
immutable thing2 t2i;
t2i = thing2(1, 2); /* doesn't compile; t2 is immutable */
For a struct like thing1 that just has some value type members, I don't
see a point in making all the members const/immutable. Making the
instances const/immutable instead is more versatile.
const is generally more useful when references are involved (pointers,
arrays, classes, ...).
Stupid question about AA. The following code works but I don't undrstand why?!
I am stupid today :) So I have a question. The piece of code given: http://dpaste.dzfl.pl/523781df67ab It looks good, but I don't understand why it works?
Practical difference between a struct with const members and with mutable members?
I'm mainly coming from languages that haven't got structs, let
alone the kind of differentiation D offers between
mutable/immutable/const/etc variables, so I'm still trying to
work out just when to use each - What's different between these
two examples, practically speaking? When would you use one over
the other?
struct thing1{
const int x, y;
}
struct thing2{
int x, y;
}
Thanks!
Re: Fiber and Thread Communication
On Friday, 8 April 2016 at 10:51:49 UTC, Nordlöw wrote: Are there any plans to unite AFAICT, it is not clear what are the limitations of the current std.concurrency and, from what. An illustrating example on task-based parallellism (such as the ones in jin.go) should partly alleviate this problem. Any ideas on what such an example should contain and illustrate. Current limitations and plans on fixing should be described aswell. References: http://forum.dlang.org/post/mailman.776.1459177268.26339.digitalmar...@puremagic.com http://code.dlang.org/packages/jin-go https://github.com/nin-jin/go.d Further, who's up for the job of add the missing parts in std.concurrency using ideas and code from https://github.com/nin-jin/go.d ? :)
Re: foreach of classes
On Saturday, 9 April 2016 at 11:03:54 UTC, Nicholas Wilson wrote: On Saturday, 9 April 2016 at 10:56:34 UTC, Lucien wrote: On Saturday, 9 April 2016 at 10:28:05 UTC, Basile B. wrote: On Saturday, 9 April 2016 at 10:10:19 UTC, Lucien wrote: Hello. FYI the things that you can put there (in place of auto) are nothing at all (type is inferred, a type, ref (the foreach variable is taken by reference), const/immutable (the variable is const or immutable). Yes, it's right that to put the type is a noop, but otherwise DCD doesn't work in foreach. Personally I think it s*c*s a lot. The manual specification of the type should be allowed.
Re: foreach of classes
On Saturday, 9 April 2016 at 10:56:34 UTC, Lucien wrote:
On Saturday, 9 April 2016 at 10:28:05 UTC, Basile B. wrote:
On Saturday, 9 April 2016 at 10:10:19 UTC, Lucien wrote:
Hello.
When I do:
-
class MyClass{..}
class YourClass{..}
class OurClass{..}
YourClass yc = new YourClass();
foreach (auto id; [ typeid(MyClass), typeid(YourClass),
typeid(OurClass) ])
{
if (typeid(yc) == id)
{
writeln("It works !");
}
}
-
The compiler says: basic type expected, not auto
Why can't I have one time the type id of MyClass, then of
YourClass and of OurClass ?
Is there an alternative ?
remove auto and optionally replaces it with TypeInfo_Class.
So simple ?! o.o
Thanks !
FYI the things that you can put there (in place of auto) are
nothing at all (type is inferred, a type, ref (the foreach
variable is taken by reference), const/immutable (the variable is
const or immutable).
Re: foreach of classes
On Saturday, 9 April 2016 at 10:28:05 UTC, Basile B. wrote:
On Saturday, 9 April 2016 at 10:10:19 UTC, Lucien wrote:
Hello.
When I do:
-
class MyClass{..}
class YourClass{..}
class OurClass{..}
YourClass yc = new YourClass();
foreach (auto id; [ typeid(MyClass), typeid(YourClass),
typeid(OurClass) ])
{
if (typeid(yc) == id)
{
writeln("It works !");
}
}
-
The compiler says: basic type expected, not auto
Why can't I have one time the type id of MyClass, then of
YourClass and of OurClass ?
Is there an alternative ?
remove auto and optionally replaces it with TypeInfo_Class.
So simple ?! o.o
Thanks !
Re: foreach of classes
On Saturday, 9 April 2016 at 10:10:19 UTC, Lucien wrote:
Hello.
When I do:
-
class MyClass{..}
class YourClass{..}
class OurClass{..}
YourClass yc = new YourClass();
foreach (auto id; [ typeid(MyClass), typeid(YourClass),
typeid(OurClass) ])
{
if (typeid(yc) == id)
{
writeln("It works !");
}
}
-
The compiler says: basic type expected, not auto
Why can't I have one time the type id of MyClass, then of
YourClass and of OurClass ?
Is there an alternative ?
remove auto and optionally replaces it with TypeInfo_Class.
foreach of classes
Hello.
When I do:
-
class MyClass{..}
class YourClass{..}
class OurClass{..}
YourClass yc = new YourClass();
foreach (auto id; [ typeid(MyClass), typeid(YourClass),
typeid(OurClass) ])
{
if (typeid(yc) == id)
{
writeln("It works !");
}
}
-
The compiler says: basic type expected, not auto
Why can't I have one time the type id of MyClass, then of
YourClass and of OurClass ?
Is there an alternative ?
Re: Interfaces
On Saturday, 9 April 2016 at 08:59:13 UTC, ag0aep6g wrote:
On 09.04.2016 10:45, alexander Patapoff wrote:
[...]
There is a somewhat obscure feature which lets you declare and
instantiate a class at the same time:
interface Action
{
void actions(int x);
}
void main()
{
Action action = new class Action {
void actions(int x) {/* ... */}
};
}
http://dlang.org/spec/class.html#anonymous
Yaaay! thank you!
Re: Interfaces
On 09.04.2016 10:45, alexander Patapoff wrote:
is there a way for me to do this in D? In java, one is able to create a
new instance of an interface.
interface Action
{
void actions(T t);
}
class testAction
{
this()
{
Action action = new Action()
{
void actions(T t){...}
}
}
}
I found this feature really useful in java. Is there any way I can
duplicate this process, without the mixin func?
There is a somewhat obscure feature which lets you declare and
instantiate a class at the same time:
interface Action
{
void actions(int x);
}
void main()
{
Action action = new class Action {
void actions(int x) {/* ... */}
};
}
http://dlang.org/spec/class.html#anonymous
Re: execute bash?
On Friday, 8 April 2016 at 23:06:06 UTC, Puming wrote: On Friday, 8 April 2016 at 18:23:32 UTC, wobbles wrote: On Friday, 8 April 2016 at 16:07:13 UTC, Adam D. Ruppe wrote: On Friday, 8 April 2016 at 15:20:09 UTC, Puming wrote: I tried with signal, but didn't catch SIGTTOU, it seems that spawnProcess with `bash -i -c` will signal with SIGTTIN. Oh, surely because it wants to be interactive and is thus waiting for user input from the terminal.. You might need to rig up a pseudo terminal that the bash can talk to. That's getting to be a pain though. You could run it through dexpect to get the effect of a pseudo terminal. https://github.com/grogancolin/dexpect Looked in the code, it is exacly what I need! Thanks. Also it has spawnInPty Cool. Any questions on using it let me know. I'm all for a bit of feedback also!
Interfaces
is there a way for me to do this in D? In java, one is able to
create a new instance of an interface.
interface Action
{
void actions(T t);
}
class testAction
{
this()
{
Action action = new Action()
{
void actions(T t){...}
}
}
}
I found this feature really useful in java. Is there any way I
can duplicate this process, without the mixin func?
Re: Is it legal to use std.windows modules?
On Saturday, 9 April 2016 at 02:14:48 UTC, Jonathan M Davis wrote: So, if anything, I'd open a bug report about how std.windows is old bug https://issues.dlang.org/show_bug.cgi?id=13516
