So now pgen.d works (without simpledisplay version an reusing trueimage).
The simpledisplay version still has problems, but I'll try (manually
(de)allocating)/(reusing) the data
2013/5/14 Adam D. Ruppe destructiona...@gmail.com
On Monday, 13 May 2013 at 21:28:34 UTC, maarten van damme wrote:
14-May-2013 08:33, Heinz пишет:
BTW, given recent discussion on memory barriers, I think my previous
statement that the mutex does not need to be locked to call notify is
probably incorrect.
Have to lock it otherwise you have a race condition on a condition
variable (wow!).
Haven't had
Very newbie question coming up :)
How does D mark null values for classes?
`c is null` returns true, but `c` isn't 0.
So how does D know `c is null`?
class C {}
C c;
assert(c is null);
assert(cast(size_t)c == 0); // fails.
On Tuesday, 14 May 2013 at 12:18:20 UTC, simendsjo wrote:
Very newbie question coming up :)
How does D mark null values for classes?
`c is null` returns true, but `c` isn't 0.
So how does D know `c is null`?
class C {}
C c;
assert(c is null);
assert(cast(size_t)c == 0); // fails.
That's the
On Tuesday, 14 May 2013 at 12:20:00 UTC, Andrej Mitrovic wrote:
On Tuesday, 14 May 2013 at 12:18:20 UTC, simendsjo wrote:
Very newbie question coming up :)
How does D mark null values for classes?
`c is null` returns true, but `c` isn't 0.
So how does D know `c is null`?
class C {}
C c;
On Tuesday, 14 May 2013 at 03:50:22 UTC, Josh wrote:
Is there a way in D to only accept input for a certain time,
instead of std.stdio.readln's behaviour? Something like Press
a key in 3 seconds to abort.
see also this thread:
http://forum.dlang.org/thread/vavskrvzebozkreub...@forum.dlang.org
On 2013-05-14 15:53, Paolo Kevin wrote:
I am trying to use a D shared library with a C program.
But I have a problem, the code works in a D program.
But it crashes as a library.
What I am doing wrong?
I think there is something the D language does before starting main.
And the C language
On Monday, 13 May 2013 at 21:04:23 UTC, Juan Manuel Cabo wrote:
There is one thing that should definitely added to the
documentation, and that is what happens when one issues a
notify while the thread hasn't yet called Condition.wait().
I can confirm that under Win32 calling notify() before
I'm doing this from my phone so please bear with me.
You use a mutex in combination with a condition variable so you
can check the state of something to determine if waiting is
necessary. So the classic producer/consumer would be something
like:
T get() {
shnchronized(c.mutex) {
14-May-2013 20:09, Heinz пишет:
On Monday, 13 May 2013 at 21:04:23 UTC, Juan Manuel Cabo wrote:
There is one thing that should definitely added to the documentation,
and that is what happens when one issues a notify while the thread
hasn't yet called Condition.wait().
I can confirm that
On Tue, 14 May 2013 00:32:49 -0400, Timothee Cour
thelastmamm...@gmail.com wrote:
I declared fun(T) as fun(T)() with the added parenthesis, and it
worked (tested on dmd 2.062 / ubuntu 64bits).
sorry I reduced wrongly.
Here's the inconsistency:
struct A {
this(T)(T x) { }
}
On Tue, 14 May 2013 04:58:27 -0400, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
14-May-2013 08:33, Heinz пишет:
BTW, given recent discussion on memory barriers, I think my previous
statement that the mutex does not need to be locked to call notify is
probably incorrect.
Have to lock it
Guys, this is a precise example of what i'm trying to do. You'll
notice that there're 2 ways of waking up the consumer:
/
Condition cond; // Previously instantiated.
bool loop = false; // This variable determine if the consumer
On May 14, 2013, at 9:09 AM, Heinz thor...@gmail.com wrote:
On Monday, 13 May 2013 at 21:04:23 UTC, Juan Manuel Cabo wrote:
There is one thing that should definitely added to the documentation, and
that is what happens when one issues a notify while the thread hasn't yet
called
On Tue, 14 May 2013 13:59:51 -0400, Heinz thor...@gmail.com wrote:
Guys, this is a precise example of what i'm trying to do. You'll notice
that there're 2 ways of waking up the consumer:
2 things:
1. D mutex locks are re-entrant. That is, you can do:
synchronized(mutex)
{
On May 14, 2013, at 10:59 AM, Heinz thor...@gmail.com wrote:
Guys, this is a precise example of what i'm trying to do. You'll notice that
there're 2 ways of waking up the consumer:
/
Condition cond; // Previously
On Tuesday, 14 May 2013 at 17:59:55 UTC, Heinz wrote:
Guys, this is a precise example of what i'm trying to do.
You'll notice that there're 2 ways of waking up the consumer:
/
Condition cond; // Previously instantiated.
bool
14-May-2013 21:02, Steven Schveighoffer пишет:
On Tue, 14 May 2013 04:58:27 -0400, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
14-May-2013 08:33, Heinz пишет:
BTW, given recent discussion on memory barriers, I think my previous
statement that the mutex does not need to be locked to call
On May 14, 2013, at 12:02 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote:
14-May-2013 21:02, Steven Schveighoffer пишет:
But since you have to lock anyway, signaling while holding the lock, or
while being outside the lock isn't really a difference.
On the level of gut feeling there
On Tue, 14 May 2013 15:19:29 -0400, Sean Kelly s...@invisibleduck.org
wrote:
If you move the notify out of the mutex then you can end up with
multiple threads competing for the same value. Say the producer puts a
value in the queue, leaves the mutex, and notifies a waiting thread.
Then
On Tuesday, 14 May 2013 at 16:01:57 UTC, Jacob Carlborg wrote:
...
I'm not sure if all this work yet. Using a D shared library
from a D application, statically linked, should work on Linux
64bit. Don't know if it works from a C application.
loading D libraries on non-Windows possible but all
I have a vector struct, Vector(T, uint N) templated on the type T
and number of components, N. I'm trying to write a function
cross which will calculate the cross product of a number of
vectors.
For a given number of components, N, the cross function should
take N-1 arguments, each one a
To Steven:
1. D mutex locks are re-entrant. That is, you can do:
synchronized(mutex)
{
synchronized(mutex)
{
...
}
}
and all is fine.
Hmmm, i guess this is what the docs meant by mutexes are
recursive, i didn't get it at first but now i do.
To test this i wrapped SetLoop()
On Wednesday, 15 May 2013 at 01:31:43 UTC, Diggory wrote:
I have a vector struct, Vector(T, uint N) templated on the type
T and number of components, N. I'm trying to write a function
cross which will calculate the cross product of a number of
vectors.
For a given number of components, N,
24 matches
Mail list logo
