On Thursday, 1 September 2016 at 13:16:19 UTC, Johan Engelen
wrote:
On Thursday, 1 September 2016 at 10:37:18 UTC, Miguel L wrote:
Also, forgot to specify I am using LDC with -05.
And the version of LDC too please ;-)
LDC version is: ldc2-1.1.0-beta2-win64-msvc
On 02/09/2016 6:01 AM, Basile B. wrote:
I've converted this section:
"configurations" : [
{
"name" : "nux32",
"dflags" : [
"objects/coff32/beaengine.o"
]
},
{
"name" : "nux64",
"dflags" : [
"objects/coff64/beaengine.o"
]
},
On Friday, 2 September 2016 at 01:53:58 UTC, Steven Schveighoffer
wrote:
On 9/1/16 9:27 PM, mogu wrote:
Here's my code in main function:
```
auto fiber = new Fiber({
while (true) {
Thread.sleep(1.seconds);
Fiber.yield;
}
});
void foo() {
On 9/1/16 9:27 PM, mogu wrote:
Here's my code in main function:
```
auto fiber = new Fiber({
while (true) {
Thread.sleep(1.seconds);
Fiber.yield;
}
});
void foo() {
while (true) {
fiber.call;
//Thread.sleep(1.sec
Here's my code in main function:
```
auto fiber = new Fiber({
while (true) {
Thread.sleep(1.seconds);
Fiber.yield;
}
});
void foo() {
while (true) {
fiber.call;
//Thread.sleep(1.seconds);
//"---".write
On Thursday, 1 September 2016 at 21:07:36 UTC, Steven
Schveighoffer wrote:
On 9/1/16 4:38 PM, Yuxuan Shui wrote:
[...]
Referring to a null object is not a problem. Your program
crashes ungracefully, but does not corrupt memory. However, in
either approach, it can easily end up being a dangli
On 9/1/16 4:38 PM, Yuxuan Shui wrote:
On Thursday, 1 September 2016 at 20:28:03 UTC, Rene Zwanenburg wrote:
On Thursday, 1 September 2016 at 19:37:25 UTC, Yuxuan Shui wrote:
[...]
This will allocate a closure. A struct definition inside a function
has a hidden context / closure pointer, unles
On Thursday, 1 September 2016 at 20:38:13 UTC, Yuxuan Shui wrote:
I think my approach is probably better, because I believe
(correct me if I'm wrong): 1) it will never refer to a null
object.
That's true, but you can ensure the same thing for the wrapper:
struct Ref()
{
@disable this();
t
On Thursday, 1 September 2016 at 18:01:19 UTC, Basile B. wrote:
I've converted this section:
[...]
to:
"buildSettings" : {
"dflags-linux-x86" : ["objects/coff32/beaengine.o"],
"dflags-linux-x86_64" : ["objects/coff64/beaengine.o"],
"dflags-windows-x86" : ["objects\\omf32\\beaengin
On Thursday, 1 September 2016 at 20:28:03 UTC, Rene Zwanenburg
wrote:
On Thursday, 1 September 2016 at 19:37:25 UTC, Yuxuan Shui
wrote:
[...]
This will allocate a closure. A struct definition inside a
function has a hidden context / closure pointer, unless it's a
static struct.
There is no
On Thursday, 1 September 2016 at 19:37:25 UTC, Yuxuan Shui wrote:
I just figured out how to store a reference:
@safe:
auto x(ref int a) {
struct A {
ref int xa() { return a; }
}
return A();
}
void main() {
import std.stdio;
int b = 10;
I just figured out how to store a reference:
@safe:
auto x(ref int a) {
struct A {
ref int xa() { return a; }
}
return A();
}
void main() {
import std.stdio;
int b = 10;
auto a = x(b);
a.xa = 20;
writeln(b); //Prints
I've converted this section:
"configurations" : [
{
"name" : "nux32",
"dflags" : [
"objects/coff32/beaengine.o"
]
},
{
"name" : "nux64",
"dflags" : [
"objects/coff64/beaengine.o"
]
},
{
"name" : "win32",
"dflags"
nvm. Renaming the MyDigestWrapper import caused the error.
On Thursday, 1 September 2016 at 09:37:22 UTC, Kagamin wrote:
Probably LDC issue https://github.com/ldc-developers/ldc/issues
Thank you for your reply. I built LDC (version 1.1.0 beta 2) from
source and ran dub using:
$ dub run --compiler="~/Downloads/ldc/bin/ldc2"
And everything works now,
On Thursday, 1 September 2016 at 10:38:07 UTC, qznc wrote:
On Thursday, 1 September 2016 at 10:30:12 UTC, Guillaume Piolat
wrote:
On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
I find the documentation on MemoryOrder lacking about the
semantics of rel. :(
[0] https://dlang.org/l
Hello all,
I'm trying to use a std.digest, namely MD5 and sHA, as a
template parameter like so:
auto x = new MyDigestWrapper!MD5;
The compiler (dmd2) then throws two error messages at me which
puzzle me.
phobos/std/traits.d 554: Error: forward reference of variable
parentPrefix, and
phob
On Thursday, 1 September 2016 at 10:37:18 UTC, Miguel L wrote:
Also, forgot to specify I am using LDC with -05.
And the version of LDC too please ;-)
On Thursday, 1 September 2016 at 11:34:28 UTC, Basile B. wrote:
On Thursday, 1 September 2016 at 11:09:18 UTC, slaid wrote:
I have a snippet:
How do I override this height field?
Thanks
The field height is not overridden. In C you have two "height".
Since your array is of type A[], map take
On Thursday, 1 September 2016 at 11:09:18 UTC, slaid wrote:
I have a snippet:
How do I override this height field?
Thanks
The field height is not overridden. In C you have two "height".
Since your array is of type A[], map takes A.height.
abstract class A
{
int height = 0;
}
class B :
On 01/09/2016 11:11 PM, Cauterite wrote:
How does one test whether a symbol is deprecated? I would have expected
something like: __traits(isDeprecated, foo).
In the compiler we have Dsymbol.isDeprecated, is that not accessible in
any way from code?
The only solution I can think of is compiling
How does one test whether a symbol is deprecated? I would have
expected something like: __traits(isDeprecated, foo).
In the compiler we have Dsymbol.isDeprecated, is that not
accessible in any way from code?
The only solution I can think of is compiling with -de and using
__traits(compiles,
I have a snippet:
import std.stdio;
import std.algorithm;
abstract class A {
int height = 0;
}
class B : A {
}
class C : A {
int height = 1;
}
void main() {
A[][int] list;
list[0] = new A[](0);
list[0] ~= new B();
list[0] ~= new C();
On Thursday, 1 September 2016 at 10:30:12 UTC, Guillaume Piolat
wrote:
On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
I find the documentation on MemoryOrder lacking about the
semantics of rel. :(
[0] https://dlang.org/library/core/atomic/memory_order.html
What helped me was to
On Thursday, 1 September 2016 at 09:53:59 UTC, Miguel L wrote:
On Thursday, 1 September 2016 at 09:36:16 UTC, Miguel L wrote:
Hi
I recently needed a very optimized array rotation algorithm,
so I did this benchmark, hope you find it interesting. I am a
bit surprised by the poor results of
std
On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
I find the documentation on MemoryOrder lacking about the
semantics of rel. :(
[0] https://dlang.org/library/core/atomic/memory_order.html
What helped me was to read std::memory_order documentation
http://en.cppreference.com/w/cpp/a
On Thursday, 1 September 2016 at 09:36:16 UTC, Miguel L wrote:
Hi
I recently needed a very optimized array rotation algorithm, so
I did this benchmark, hope you find it interesting. I am a bit
surprised by the poor results of std.algorithm.bringToFront:
[...]
Sorry Rotate4 had a bug, there
Probably LDC issue https://github.com/ldc-developers/ldc/issues
Hi
I recently needed a very optimized array rotation algorithm, so I
did this benchmark, hope you find it interesting. I am a bit
surprised by the poor results of std.algorithm.bringToFront:
These are the different algorithms:
void Rotate0(T)(T[] input, int n) pure
{
if(n>0)input=in
On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
This effectively makes the access to the protected value
unprotected and nullifies the effect of the spinlock.
So the cas operation implicit an MemoryOrder.acq? Does it make
any other MemoryOrder guarantee?
On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
I'm not sure I understand rel [0], but raw is too weak. Raw
means no sequencing barrier, so
local_var = protected_value;
spinlock.unlock();
could be transformed (by compiler or CPU) to
spinlock.unlock();
local_var = protecte
On Thursday, 1 September 2016 at 06:44:13 UTC, mogu wrote:
I found an implementation of spinlock in concurrency.d.
```
static shared struct SpinLock
{
void lock() { while (!cas(&locked, false, true)) {
Thread.yield(); } }
void unlock() { atomicStore!(MemoryOrder.rel)(locked,
false); }
32 matches
Mail list logo