Problems with dmd Switches in Makefiles
I know I'm supposed to use dub, but I'm not ready. I just found out I can't use dmd switches for file names variable in a GNU makefile, e.g., see this fragment %.o : %.d dmd -c $< -of $@ which doesn't work because the "-of" must be followed immediately by a file name with no intervening spaces. This simple case works by simply removing the code chunk "-of $@" but the problem precludes more complex makefiles. Also, I notice dmd has no simple way to output its version (by the way, I'm using dmd version 2.065 installed via the Debian apt package management system). Am I missing something, or are these situations legitimate bugs? Thanks. Best regards, -Tom
Re: Problems with dmd Switches in Makefiles
On Saturday, 17 May 2014 at 13:01:07 UTC, Tom Browder via Digitalmars-d-learn wrote: I know I'm supposed to use dub, but I'm not ready. I just found out I can't use dmd switches for file names variable in a GNU makefile, e.g., see this fragment %.o : %.d dmd -c $< -of $@ which doesn't work because the "-of" must be followed immediately by a file name with no intervening spaces. dmd -c $< -of$@ works for me with GNU Make 3.82.
Re: Problems with dmd Switches in Makefiles
On Sat, May 17, 2014 at 8:05 AM, via Digitalmars-d-learn wrote: > On Saturday, 17 May 2014 at 13:01:07 UTC, Tom Browder via > Digitalmars-d-learn wrote: ... >> I just found out I can't use dmd switches for file names variable in a >> GNU makefile, e.g., see this fragment ... >> dmd -c $< -of$@ >> >> which doesn't work > works for me with GNU Make 3.82. You're correct, my error. I had another error which I misinterpreted. So GNU make expands the "$@" variable even without the space after "-of"--great! Thanks for the help. Best regards, -Tom
Re: Objects(from classes) at Compile time? no gc
On Friday, 16 May 2014 at 22:48:08 UTC, Taylor Hillegeist wrote: Although, I don't know if it will allocate it during runtime as well. It will not. -Steve Does this work in GDC? Can't test in GDC, but it does work in LDC, and I see no reason why it shouldn't, because this functionality is implemented in the frontend, which DMD, GDC and LDC share.
std.concurrency thread communication problem
I'm building a program which I intend to have many threads that can each send messages to (and receive messages from) each other. The obvious way to do this would be to have a shared array of Tids, but this seems to not work. I'm continually fighting the system to get it to compile, and this makes me think it should probably be done some other way...but what? One possibility is to have each thread maintain a separate array that contains all the threads, which would mean that they would need to be initialized after they were created. This would avoid the problems of shared Tids, but each Tid contains a private mailbox, so this would be being duplicated, and that bothers me...it seems like a poor idea. (Maybe I'm wrong about that...but I don't know.) I do know that I want a n by n communication matrix (leaving out the main thread), with each thread sending messages to all to others. (Well, except for a few that I haven't really defined yet, but which handle separated functions.) My plan was to have each thread run an execution loop which frequently checked for messages received in between performing its own functions. They are not intended to synchronize with each other. They are not intended to be temporary, i.e., each of these threads would be started shortly after program initialization, and continue running until program termination. But how should I get them to know each other's address? I don't want the main thread to need to act as a switchboard between all the others, though I guess that would "sort of" work. (Actually, if I need to do that, that job would be pulled off into yet another thread...and I end up with more threads than processors. Still, that's a design that is possible, IIUC.) Any comments or suggestions?
Re: D Newbie Trying to Use D with Major C Libraries
On Friday, 16 May 2014 at 18:19:45 UTC, Alex Herrmann wrote: On Friday, 16 May 2014 at 10:10:17 UTC, Tom Browder via Digitalmars-d-learn wrote: Thanks for the suggestion, Frank, but I don't do windows. Monodevelop (open source C# dev platform) has a plugin for D by Alexander Bothe called Mono-D which is absolutely fantastic and integrates okay with dub too. There is also an emacs major mode for d (d-mode) which gives basic highlighting and indentation too. I use both all of these tools on my Arch linux set up and they work very well, and Mono-D has some debugging support too. Best of luck spreading D Tom! You're doing the lord's work son. Alex I am very happy with d-mode in emacs.
Re: std.concurrency thread communication problem
On Saturday, 17 May 2014 at 18:43:25 UTC, Charles Hixson via Digitalmars-d-learn wrote: I'm building a program which I intend to have many threads that can each send messages to (and receive messages from) each other. The obvious way to do this would be to have a shared array of Tids, but this seems to not work. I'm continually fighting the system to get it to compile, and this makes me think it should probably be done some other way...but what? One possibility is to have each thread maintain a separate array that contains all the threads, which would mean that they would need to be initialized after they were created. This would avoid the problems of shared Tids, but each Tid contains a private mailbox, so this would be being duplicated, and that bothers me...it seems like a poor idea. (Maybe I'm wrong about that...but I don't know.) If my understanding is correct, each Tid contains a reference to the corresponding thread's MessageBox (implemented by way of MessageBox being a class), not an independent instance. You should be fine to just have an array of the relevant Tids in each thread. Alternatively, a single __gshared array of threads should work, given you are sufficiently careful with it. Remember, if no-one is doing any writing then you don't need to do any synchronisation of reads.
Re: std.concurrency thread communication problem
On 05/17/2014 12:33 PM, John Colvin wrote:
On Saturday, 17 May 2014 at 18:43:25 UTC, Charles Hixson via
Digitalmars-d-learn wrote:
I'm building a program which I intend to have many threads that can
each send
messages to (and receive messages from) each other. The obvious way
to do
this would be to have a shared array of Tids, but this seems to not
work. I'm
continually fighting the system to get it to compile, and this makes
me think
it should probably be done some other way...but what?
One possibility is to have each thread maintain a separate array that
contains
all the threads, which would mean that they would need to be
initialized after
they were created. This would avoid the problems of shared Tids, but
each Tid
contains a private mailbox, so this would be being duplicated, and that
bothers me...it seems like a poor idea. (Maybe I'm wrong about
that...but I
don't know.)
If my understanding is correct, each Tid contains a reference to the
corresponding thread's MessageBox (implemented by way of MessageBox
being a class), not an independent instance. You should be fine to just
have an array of the relevant Tids in each thread.
Alternatively, a single __gshared array of threads should work, given
you are sufficiently careful with it. Remember, if no-one is doing any
writing then you don't need to do any synchronisation of reads.
The following is what I've come up with. I had to use a number of
shared-related casts.
import std.stdio;
import std.concurrency;
import std.datetime;
import std.random;
import core.thread;
enum threadCount = 5;
enum messagePerThread = 3;
// Represents messages sent to threads to start their tasks
struct Start
{}
// Receives the number (id) of this thread and the workers to send
messages to
void workerFunc(size_t id, shared(Tid)[] workers)
{
receiveOnly!Start();
// A local function to reduce code duplication
bool checkMessageForMe(Duration timeout)
{
return receiveTimeout(
timeout,
(size_t from) {
writefln("%s received from %s", id, from);
});
}
// My main task is to send messages to others:
size_t totalSent = 0;
while (totalSent < messagePerThread) {
auto to = uniform(0, workers.length);
// Only send to others; not to self
if (to != id) {
auto chosen = cast(Tid)workers[to];
writefln("%s sending to %s", id, to);
chosen.send(id);
++totalSent;
}
checkMessageForMe(0.seconds);
}
// Process trailing messages sent to me
bool received = false;
do {
received = checkMessageForMe(10.msecs);
} while (received);
}
void main()
{
auto workers = new shared(Tid)[threadCount];
foreach (id; 0 .. threadCount) {
auto worker = spawn(&workerFunc, id, workers);
workers[id] = cast(shared(Tid))worker;
}
foreach (sharedWorker; workers) {
auto worker = cast(Tid)sharedWorker;
worker.send(Start());
}
thread_joinAll();
}
Sample output:
0 sending to 2
4 sending to 3
4 sending to 2
1 sending to 4
3 received from 4
3 sending to 2
0 sending to 1
4 received from 1
1 received from 0
1 sending to 0
0 received from 1
0 sending to 1
1 received from 0
1 sending to 0
0 received from 1
3 sending to 2
4 sending to 2
2 sending to 0
2 received from 0
2 received from 4
3 sending to 1
2 sending to 3
0 received from 2
1 received from 3
2 received from 3
2 sending to 0
3 received from 2
0 received from 2
2 received from 3
2 received from 4
Ali
Re: Array!T and find are slow
On Fri, 16 May 2014 11:51:31 -0400
Steven Schveighoffer via Digitalmars-d-learn
wrote:
> On Fri, 16 May 2014 11:36:44 -0400, Jonathan M Davis via
> Digitalmars-d-learn wrote:
>
> > On Thu, 15 May 2014 08:04:59 -0300
> > Ary Borenszweig via Digitalmars-d-learn
> > wrote:
> >
> >> Isn't there a way in D to just expand:
> >>
> >> enforce(cond, "failure");
> >>
> >> (or something with a similar syntax) to this, at compile-time:
> >>
> >> if(!cond) throw new Exception("failure");
> >>
> >> I thought D could do this, so enforce should do this instead of
> >> using lazy arguments.
> >
> > No. enforce is a function, and the only other things that it could
> > be with
> > that syntax would be other callables (e.g. a lambda, delegate, or
> > functor).
>
> I think it *could* optimize properly, and that would be an amazing
> improvement to the compiler, if someone wants to implement that.
>
> Essentially, you need to be able to inline enforce (not a problem
> since it's a template), and then deduce that the lazy calls can just
> be moved to where they are used, in this case, only once.
>
> This would make a logging library even better too.
Sure, the compiler could be improved to optimize enforce such that
enforce(cond, "failure");
becomes
if(!cond) throw new Exception("failure");
And I think that that's what needs to be done. However, what I understood the
question to be was whether there was a construct in the language that we could
use where
enforce(cond, "failure");
would be automatically converted to
if(!cond) throw new Exception("failure");
without the compiler having to do optimizations to make it happen. The closest
to that would be mixins, but they can't do it with the same syntax. You'd be
required to write something more complex to use mixins to do the job.
But I think that the correct solution is to improve the compiler with regards
to lazy. The fact that lazy is so slow is a serious problem, and enforce is
just one manifestation of it (albeit the worst because of how often it's
used).
- Jonathan M Davis
Re: D Newbie Trying to Use D with Major C Libraries
On Sat, May 17, 2014 at 2:28 PM, Mengu via Digitalmars-d-learn wrote: > On Friday, 16 May 2014 at 18:19:45 UTC, Alex Herrmann wrote: ... >> integrates okay with dub too. There is also an emacs major mode >> for d (d-mode) which gives basic highlighting and indentation >> too. I use both all of these tools on my Arch linux set up and >> they work very well ... > I am very happy with d-mode in emacs. Thanks for the reports, Alex and Mengu. I have installed the d-mode for xemacs but I don't have it working properly yet. I'll probably have to ask for help with that before too long. Best, -Tom
Re: Array!T and find are slow
On Saturday, 17 May 2014 at 20:06:03 UTC, Jonathan M Davis via Digitalmars-d-learn wrote: But I think that the correct solution is to improve the compiler with regards to lazy. The fact that lazy is so slow is a serious problem, and enforce is just one manifestation of it (albeit the worst because of how often it's used). - Jonathan M Davis I haven't been bitten by the performance of lazy myself, but I'd +1 that, because of how easy it can make writing code.
Re: std.concurrency thread communication problem
On Saturday, May 17, 2014 12:59:22 PM Ali Çehreli via Digitalmars-d-learn
wrote:
> On 05/17/2014 12:33 PM, John Colvin wrote:
> > On Saturday, 17 May 2014 at 18:43:25 UTC, Charles Hixson via
> >
> > Digitalmars-d-learn wrote:
> >> I'm building a program which I intend to have many threads that can
> >> each send
> >> messages to (and receive messages from) each other. The obvious way
> >> to do
> >> this would be to have a shared array of Tids, but this seems to not
> >> work. I'm
> >> continually fighting the system to get it to compile, and this makes
> >> me think
> >> it should probably be done some other way...but what?
> >>
> >> One possibility is to have each thread maintain a separate array that
> >> contains
> >> all the threads, which would mean that they would need to be
> >> initialized after
> >> they were created. This would avoid the problems of shared Tids, but
> >> each Tid
> >> contains a private mailbox, so this would be being duplicated, and that
> >> bothers me...it seems like a poor idea. (Maybe I'm wrong about
> >> that...but I
> >> don't know.)
> >
> > If my understanding is correct, each Tid contains a reference to the
> > corresponding thread's MessageBox (implemented by way of MessageBox
> > being a class), not an independent instance. You should be fine to just
> > have an array of the relevant Tids in each thread.
> >
> > Alternatively, a single __gshared array of threads should work, given
> > you are sufficiently careful with it. Remember, if no-one is doing any
> > writing then you don't need to do any synchronisation of reads.
>
> The following is what I've come up with. I had to use a number of
> shared-related casts.
>
> import std.stdio;
> import std.concurrency;
> import std.datetime;
> import std.random;
> import core.thread;
>
> enum threadCount = 5;
> enum messagePerThread = 3;
>
> // Represents messages sent to threads to start their tasks
> struct Start
> {}
>
> // Receives the number (id) of this thread and the workers to send
> messages to
> void workerFunc(size_t id, shared(Tid)[] workers)
> {
> receiveOnly!Start();
>
> // A local function to reduce code duplication
> bool checkMessageForMe(Duration timeout)
> {
> return receiveTimeout(
> timeout,
> (size_t from) {
> writefln("%s received from %s", id, from);
> });
> }
>
> // My main task is to send messages to others:
> size_t totalSent = 0;
> while (totalSent < messagePerThread) {
> auto to = uniform(0, workers.length);
>
> // Only send to others; not to self
> if (to != id) {
> auto chosen = cast(Tid)workers[to];
> writefln("%s sending to %s", id, to);
> chosen.send(id);
> ++totalSent;
> }
>
> checkMessageForMe(0.seconds);
> }
>
> // Process trailing messages sent to me
> bool received = false;
> do {
> received = checkMessageForMe(10.msecs);
> } while (received);
> }
>
> void main()
> {
> auto workers = new shared(Tid)[threadCount];
>
> foreach (id; 0 .. threadCount) {
> auto worker = spawn(&workerFunc, id, workers);
> workers[id] = cast(shared(Tid))worker;
> }
>
> foreach (sharedWorker; workers) {
> auto worker = cast(Tid)sharedWorker;
> worker.send(Start());
> }
>
> thread_joinAll();
> }
>
> Sample output:
>
> 0 sending to 2
> 4 sending to 3
> 4 sending to 2
> 1 sending to 4
> 3 received from 4
> 3 sending to 2
> 0 sending to 1
> 4 received from 1
> 1 received from 0
> 1 sending to 0
> 0 received from 1
> 0 sending to 1
> 1 received from 0
> 1 sending to 0
> 0 received from 1
> 3 sending to 2
> 4 sending to 2
> 2 sending to 0
> 2 received from 0
> 2 received from 4
> 3 sending to 1
> 2 sending to 3
> 0 received from 2
> 1 received from 3
> 2 received from 3
> 2 sending to 0
> 3 received from 2
> 0 received from 2
> 2 received from 3
> 2 received from 4
>
> Ali
Thank you immensely. That is precisely the kind of information I was hoping
for.
randomSample
How do I get an array from randomSample()? int[] source = [ ... ]; int[] sample = randomSample(source, 3); src\main.d(30): Error: cannot implicitly convert expression (randomSample(source, 3u)) of type RandomSample!(int[], void) to int[] I get that RandomSample is a struct which implements the necessary interface to work with foreach. But the fact that this struct is considered a proprietary implementation detail of std.random is a constant source of frustration for me. Quite a few D libraries use this trick, but the opacity of these data structures make it impossible for users to know exactly how to use them outside of the one or two examples given in the documentation. I don't know how to improve the situation, other than documenting them explicitly rather than treating them as a magical black box. In the mean time, can anyone suggest a solution to the above, short of actually iterating over it? I suppose someone will say to use map!(). Dave
Re: randomSample
On 5/17/2014 9:18 PM, David Held wrote: How do I get an array from randomSample()? int[] source = [ ... ]; int[] sample = randomSample(source, 3); src\main.d(30): Error: cannot implicitly convert expression (randomSample(source, 3u)) of type RandomSample!(int[], void) to int[] [...] Even worse, foreach is brittle: foreach (i, a; randomSample(source, 3)) src\main.d(30): Error: cannot infer argument types If I remove the index variable, it works. But I really need the index too. Dave
Re: randomSample
On Sunday, 18 May 2014 at 04:19:05 UTC, David Held wrote: How do I get an array from randomSample()? int[] source = [ ... ]; int[] sample = randomSample(source, 3); src\main.d(30): Error: cannot implicitly convert expression (randomSample(source, 3u)) of type RandomSample!(int[], void) to int[] I get that RandomSample is a struct which implements the necessary interface to work with foreach. But the fact that this struct is considered a proprietary implementation detail of std.random is a constant source of frustration for me. Quite a few D libraries use this trick, but the opacity of these data structures make it impossible for users to know exactly how to use them outside of the one or two examples given in the documentation. I don't know how to improve the situation, other than documenting them explicitly rather than treating them as a magical black box. In the mean time, can anyone suggest a solution to the above, short of actually iterating over it? I suppose someone will say to use map!(). Dave You need to use the function array from std.array. import std.array; int[] source = [ ... ]; int[] sample = randomSample(source, 3).array(); Array has the ability to turn any range into an array, and it's generally how you convert from these structs (which generally implement a range interface) returned by most range-based functions in D. It can be a bit confusing at first, but returning a range struct is much more flexible than returning a simple array of values.
