Re: Compiler magic for preventing memory access re-ordering _by the compiler_ (keywords: memory model, compiler optimisations, memory order)

2017-11-05 Thread Michael V. Franklin via Digitalmars-d-learn
On Monday, 6 November 2017 at 05:54:00 UTC, Michael V. Franklin wrote: On Monday, 6 November 2017 at 03:40:23 UTC, Cecil Ward wrote: Is there a magic visible sign (or even one needed) in the D language that tells D _compilers_ not to move certain types of memory load / store operations

Re: Compiler magic for preventing memory access re-ordering _by the compiler_ (keywords: memory model, compiler optimisations, memory order)

2017-11-05 Thread Michael V. Franklin via Digitalmars-d-learn
On Monday, 6 November 2017 at 03:40:23 UTC, Cecil Ward wrote: Is there a magic visible sign (or even one needed) in the D language that tells D _compilers_ not to move certain types of memory load / store operations forwards or backwards relative to other operations when optimising the code

Compiler magic for preventing memory access re-ordering _by the compiler_ (keywords: memory model, compiler optimisations, memory order)

2017-11-05 Thread Cecil Ward via Digitalmars-d-learn
I have to apologise in advance for a truly dumb question, so please be kind. Is there a magic visible sign (or even one needed) in the D language that tells D _compilers_ not to move certain types of memory load / store operations forwards or backwards relative to other operations when

Re: problem with multiwayMerge and chunkBy

2017-11-05 Thread Nicholas Wilson via Digitalmars-d-learn
On Sunday, 5 November 2017 at 22:47:10 UTC, Nicholas Wilson wrote: f.multiwayMerge.chunks(128).joiner.chunkBy!(pred).writeln; since it seems to be the iteration that stuff things up and this changes it. If that doesn't work you could try rolling your own version of chunk with `take` and a

Re: problem with multiwayMerge and chunkBy

2017-11-05 Thread Nicholas Wilson via Digitalmars-d-learn
On Sunday, 5 November 2017 at 13:32:57 UTC, Matthew Gamble wrote: On Sunday, 5 November 2017 at 03:21:06 UTC, Nicholas Wilson wrote: On Saturday, 4 November 2017 at 18:57:17 UTC, Matthew Gamble wrote: [...] It should, this looks like a bug somewhere, please file one at issues.dlang.org/ .

Creating a C# like Asynchronous Socket

2017-11-05 Thread DrCataclysm via Digitalmars-d-learn
I am trying to build something like the asynchronous Sockets from C# .NET but I'm stuck at the accepting phase. My code is something like this: public class TCPListener { ushort _port; string _address; bool _active; string _lineEnd; ubyte[] _messageBuffer; Socket

Re: Strange AV in asm mode (code only for amd64)

2017-11-05 Thread user1234 via Digitalmars-d-learn
On Sunday, 5 November 2017 at 14:27:18 UTC, Eugene Wissner wrote: On Sunday, 5 November 2017 at 13:43:15 UTC, user1234 wrote: [...] One of the problems is that "naked" is missing in your assembly. If you write asm pure nothrow { naked; mov RAX, 1; ret;

Re: Strange AV in asm mode (code only for amd64)

2017-11-05 Thread user1234 via Digitalmars-d-learn
On Sunday, 5 November 2017 at 13:43:15 UTC, user1234 wrote: [...] Hmmm it was just the amount of nops. --- import std.stdio; alias Proc = size_t function(); size_t allInnOne() { asm pure nothrow { naked; mov RAX, 1; ret; nop;nop; mov RAX, 2;

Re: Strange AV in asm mode (code only for amd64)

2017-11-05 Thread Eugene Wissner via Digitalmars-d-learn
On Sunday, 5 November 2017 at 13:43:15 UTC, user1234 wrote: Hello, try this: --- import std.stdio; alias Proc = size_t function(); size_t allInnOne() { asm pure nothrow { mov RAX, 1; ret; nop;nop;nop;nop;nop;nop;nop; mov RAX, 2; ret; } }

Strange AV in asm mode (code only for amd64)

2017-11-05 Thread user1234 via Digitalmars-d-learn
Hello, try this: --- import std.stdio; alias Proc = size_t function(); size_t allInnOne() { asm pure nothrow { mov RAX, 1; ret; nop;nop;nop;nop;nop;nop;nop; mov RAX, 2; ret; } } void main() { Proc proc1 = Proc proc2 = cast(Proc)

Re: problem with multiwayMerge and chunkBy

2017-11-05 Thread Matthew Gamble via Digitalmars-d-learn
On Sunday, 5 November 2017 at 03:21:06 UTC, Nicholas Wilson wrote: On Saturday, 4 November 2017 at 18:57:17 UTC, Matthew Gamble wrote: [...] It should, this looks like a bug somewhere, please file one at issues.dlang.org/ . in the mean time struct Replicate(T) { Tuple!(T, uint) e;

Re: Alias this and inheritance

2017-11-05 Thread ag0aep6g via Digitalmars-d-learn
On Sunday, 5 November 2017 at 07:07:43 UTC, Aurelien Fredouelle wrote: struct S { } class A { S s; alias s this; } class B : A { } void main() { A asA = new B; B asB = cast(B)asA; } I would expect the last line to successfully cast the B instance I created back into type B, however

Re: Debug info for druntime.

2017-11-05 Thread Joakim via Digitalmars-d-learn
On Saturday, 4 November 2017 at 21:54:14 UTC, ciechowoj wrote: What is the fastest way to have the detailed debug info for druntime? I have a program that fails in Fiber constructor after I create and delete at least 68_209 Fibers one after another. For 68_208 works fine, one more and it

Alias this and inheritance

2017-11-05 Thread Aurelien Fredouelle via Digitalmars-d-learn
The following code does not compile: struct S { } class A { S s; alias s this; } class B : A { } void main() { A asA = new B; B asB = cast(B)asA; } I would expect the last line to successfully cast the B instance I created back into type B, however this seems to be preempted by the