This compiles. Is it supposed to?
@safe ubyte[] foo()
{
ubyte[512] buf;
auto slice = buf[0..$];
// Escaping reference to stack memory, right?
return slice;
}
Or is the escaping reference detection not intended to be 100%? Or
something else I'm missing?
Should I
On 10/14/16 4:49 PM, Nick Sabalausky wrote:
This compiles. Is it supposed to?
@safe ubyte[] foo()
{
ubyte[512] buf;
auto slice = buf[0..$];
// Escaping reference to stack memory, right?
return slice;
}
Yes, this still is a problem, but Walter has a fix in the works.
https://is
On Friday, 14 October 2016 at 15:13:58 UTC, Jonathan M Davis
wrote:
On Thursday, October 13, 2016 19:07:44 Nordlöw via
Digitalmars-d-learn wrote:
Is there a large speed difference in compilation time
depending on whether the DMD used is built using DMD or LDC?
I would be shocked if there weren
On Saturday, 15 October 2016 at 07:39:31 UTC, ketmar wrote:
p.s. this is all about GNU/Linux on x86 arch. for other OS/arch
it may be completely different.
On Saturday, 15 October 2016 at 05:41:05 UTC, Walter Bright wrote:
The problem is the closure is generated when it is expected
that the delegate will survive past the end of the scope (it's
the whole point of a closure). But with a destructor that runs
at the end of the scope, it cannot survive
On Saturday, 15 October 2016 at 07:55:30 UTC, ketmar wrote:
p.s. compiler doesn't complain each time, only in some
circumstances. i don't remember the exact code now, but some of
it has nothing to do with closures at all -- no std.algo, no
templates with lambda args, etc.
Hi,
I want to use the variables from dub.json. For example, use the
parameter "name" to display information message. Now I read
dub.json. Is there a way to import them?
Please excuse any mistakes as English is my second language.
On Saturday, 15 October 2016 at 17:36:10 UTC, Gustav wrote:
Hi,
I want to use the variables from dub.json. For example, use the
parameter "name" to display information message. Now I read
dub.json. Is there a way to import them?
Please excuse any mistakes as English is my second language.
On Thursday, 13 October 2016 at 17:02:32 UTC, Nordlöw wrote:
I just upgraded my Ubuntu to 16.10 and now my rebuilding of dmd
from git master fails as
/usr/bin/ld: idgen.o: relocation R_X86_64_32 against symbol
`__dmd_personality_v0' can not be used when making a shared
object; recompile with
On Sunday, 16 October 2016 at 08:41:26 UTC, Christian Köstlin
wrote:
Hi,
for an exercise I had to implement a thread safe counter. This
is what I came up with:
[...]
Could you try that:
class ThreadSafe3Counter: Counter{
private long counter;
private core.sync.mutex.Mutex mtx;
publi
On Sunday, 16 October 2016 at 17:42:44 UTC, tcak wrote:
On Thursday, 13 October 2016 at 17:02:32 UTC, Nordlöw wrote:
[...]
I have upgraded my Ubuntu to 16.10 yesterday as well, and I am
getting following error:
/usr/bin/ld: obj/Debug/program.o: relocation R_X86_64_32
against symbol `_D9Exc
Hi,
for an exercise I had to implement a thread safe counter.
This is what I came up with:
---SNIP---
import std.stdio;
import core.thread;
import std.conv;
import std.datetime;
static import core.atomic;
import core.sync.mutex;
int NR_OF_THREADS = 100;
int NR_OF_INCREMENTS = 1;
interface
On Saturday, 15 October 2016 at 07:39:31 UTC, ketmar wrote:
On Friday, 14 October 2016 at 15:13:58 UTC, Jonathan M Davis
wrote:
On Thursday, October 13, 2016 19:07:44 Nordlöw via
Digitalmars-d-learn wrote:
Is there a large speed difference in compilation time
depending on whether the DMD used i
On Sunday, 16 October 2016 at 20:01:21 UTC, tcak wrote:
Hmm. As the error message says, I compiled the program by
adding "-fPIC", it really has stopped giving error messages.
That came to me weird.
Which flag(s) in `src/posix.mak` did you change?
void test(string line){
...
};
void main(){
string[] list;
foreach (line; list)
new Thread({test(line);}).start();
...
}
On Sunday, 16 October 2016 at 22:00:48 UTC, Nordlöw wrote:
Which flag(s) in `src/posix.mak` did you change?
Does
make -f posix.mak MODEL_FLAG=-fPIC
work?
I'm sitting on a 16.04 system right now (which I don't dare to
upgrade until this is fixed) so I'm just guessing.
I have in mind a project to render instruments (speed, pressure,
position) to a screen using SVG. I am able to produce the SVG
easily enough. What I am looking for is a library/canvas/toolkit
that I can use in D inside of a loop and update the instrument
readouts.
This whole project is a vehi
On 10/16/2016 03:22 PM, markov wrote:
void test(string line){
...
};
void main(){
string[] list;
foreach (line; list)
new Thread({test(line);}).start();
...
}
It works in an unexpected way: In D, all those threads would close over
the same 'line' loop variable, which happens to poi
On 17/10/2016 2:20 PM, Jason C. Wells wrote:
I have in mind a project to render instruments (speed, pressure,
position) to a screen using SVG. I am able to produce the SVG easily
enough. What I am looking for is a library/canvas/toolkit that I can use
in D inside of a loop and update the instrume
Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a):
My question now is, why is each mutex based thread safe variant so slow
compared to a similar java program? The only hint could be something
like:
https://blogs.oracle.com/dave/entry/java_util_concurrent_reentrantlock_vs
On Sunday, 16 October 2016 at 22:36:15 UTC, Nordlöw wrote:
On Sunday, 16 October 2016 at 22:00:48 UTC, Nordlöw wrote:
Which flag(s) in `src/posix.mak` did you change?
Does
make -f posix.mak MODEL_FLAG=-fPIC
work?
I'm sitting on a 16.04 system right now (which I don't dare to
upgrade un
On 16/10/16 19:50, tcak wrote:
> On Sunday, 16 October 2016 at 08:41:26 UTC, Christian Köstlin wrote:
>> Hi,
>>
>> for an exercise I had to implement a thread safe counter. This is what
>> I came up with:
>>
>> [...]
>
> Could you try that:
>
> class ThreadSafe3Counter: Counter{
> private long
On 17/10/16 06:55, Daniel Kozak via Digitalmars-d-learn wrote:
> Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a):
>
>> My question now is, why is each mutex based thread safe variant so slow
>> compared to a similar java program? The only hint could be something
>> like:
Dne 17.10.2016 v 07:55 Christian Köstlin via Digitalmars-d-learn napsal(a):
to run java call ./gradlew clean build
->
counter.AtomicIntCounter@25992ae3 expected: 200 got: 100 in: 22ms
counter.AtomicLongCounter@2539f946 expected: 200 got: 100 in: 17ms
counter.ThreadSafe2Counter@52
On Monday, 17 October 2016 at 06:38:08 UTC, Daniel Kozak wrote:
Dne 17.10.2016 v 07:55 Christian Köstlin via
Digitalmars-d-learn napsal(a):
[...]
I am still unable to get your java code working:
[kozak@dajinka threads]$ ./gradlew clean build
:clean
:compileJava
:processResources UP-TO-DATE
:c
25 matches
Mail list logo
