On Wed, 15 May 2013 03:31:40 +0200, 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, the c
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, t
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()
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 Ve
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 al
On Monday, 13 May 2013 at 00:18:34 UTC, D-Ratiseur wrote:
I went back from a trip...basically I spent 6 monthes in
Yukon...
Then, came back to my activities, I was a lot in the library of
the university linked to my geo. location...I've noticed a
strange guy...He was always reading some books a
On Tue, 14 May 2013 15:19:29 -0400, Sean Kelly
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 consumer A enters the
On May 14, 2013, at 12:02 PM, Dmitry Olshansky 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 must be somet
14-May-2013 21:02, Steven Schveighoffer пишет:
On Tue, 14 May 2013 04:58:27 -0400, Dmitry Olshansky
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 incorr
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 lo
On May 14, 2013, at 10:59 AM, 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 l
On Tue, 14 May 2013 13:59:51 -0400, 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:
2 things:
1. D mutex locks are re-entrant. That is, you can do:
synchronized(mutex)
{
synchronized(mutex)
{
On May 14, 2013, at 9:09 AM, Heinz 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 Condition.wait().
>
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 Tue, 14 May 2013 04:58:27 -0400, Dmitry Olshansky
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
On Tue, 14 May 2013 00:32:49 -0400, Timothee Cour
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) { }
}
auto fun1(){
au
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 under
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) {
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 w
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 do
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.
Here is a minimal example.
I want to make a library that returns an array of 100 integers.
% ls
fakemain.d function.d main.c
% cat fakemain.d
void main() {}
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.or
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;
asser
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.
"&c" is ad
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
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.
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 an
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
> On Monday, 13 May 2013 at 21:28:34 UTC, maarten van damme wrote:
>
>> Adam checks this thre
28 matches
Mail list logo
