On Friday, 1 March 2013 at 07:11:49 UTC, Jacob Carlborg wrote:
On 2013-02-28 22:45, rho wrote:
thats too bad. you guys do wonderful things, but it the needs
of the
common user seem to be forgotten by the creators of D. they
should
change that.
I don't understand how you can say that. 32bit
On Thursday, 28 February 2013 at 09:35:03 UTC, rho wrote:
hi,
what keeps me from using d, is that there is no compilable gui
lib available. does dfl compile with the latest dmd?
I am using DFL successfully with DMD 2.062. One just needs to
take sources from here:
On 1-3-2013 10:03, thedeemon wrote:
On Thursday, 28 February 2013 at 09:35:03 UTC, rho wrote:
hi,
what keeps me from using d, is that there is no compilable gui lib available.
does dfl compile with the latest dmd?
I am using DFL successfully with DMD 2.062. One just needs to take sources
On 2013-03-01 09:37, Andrea Fontana wrote:
You're saying you can't build gui for app that use 64bit features. You
force the whole app to be compiled on 32bit just because gui needs 32bit.
Yes, what do you need so badly that cannot be done with a 32bit app?
If you're working on linux, you
I am using DFL successfully with DMD 2.062. One just needs to
take sources from here:
https://github.com/Rayerd/dfl
I just saw this rep updated a few days ago, now it should build
just fine with latest DMD without manual changes to the source.
On Friday, 1 March 2013 at 09:07:12 UTC, Jacob Carlborg wrote:
On 2013-03-01 09:37, Andrea Fontana wrote:
You're saying you can't build gui for app that use 64bit
features. You
force the whole app to be compiled on 32bit just because gui
needs 32bit.
Yes, what do you need so badly that
On Thursday, 28 February 2013 at 14:15:57 UTC, Joseph Rushton
Wakeling wrote:
In other words, it doesn't seem possible to get more than about
2 * speedup on
my system from using concurrency, even though there should not
be any data races or other factors that might explain slower
On 03/01/2013 11:43 AM, thedeemon wrote:
Two ideas coming to mind:
1) Amdahl's law. If there is some locking inside random numbers generator, you
will never get linear speed up.
I had some concerns here. rndGen is supposed to be thread-safe, which was
incidentally why I was using
When trying to implement non-POD types for gdc some time ago I asked on
the dmd mailing list what the backend is actually supposed to do for
non-POD types. Walter answered that they should never be passed in
registers:
--
Wouldn't it be legal to still pass non-PODs in
On Friday, 1 March 2013 at 13:59:08 UTC, Johannes Pfau wrote:
When trying to implement non-POD types for gdc some time ago I
asked on
the dmd mailing list what the backend is actually supposed to
do for
non-POD types. Walter answered that they should never be passed
in
registers:
I'm trying to do something like this. I don't know whether or not
it's a good idea, i'm open to solutions and suggestions
struct MyStruct(WEIGHTS)
{
string ...
string ...
alias WEIGHTS weights;
}
double likeness(T,T1)(ref in T1, ref in T2)
{
// Here i do some complex calculus
On Friday, 1 March 2013 at 14:27:40 UTC, Andrea Fontana wrote:
I'm trying to do something like this. I don't know whether or
not it's a good idea, i'm open to solutions and suggestions
struct MyStruct(WEIGHTS)
{
string ...
string ...
alias WEIGHTS weights;
}
double
On Friday, 1 March 2013 at 14:39:53 UTC, bearophile wrote:
Andrea Fontana:
double likeness(T,T1)(ref in T1, ref in T2)
==
double likeness(T1, T2)(in ref T1, in ref T2)
Bye,
bearophile
Sure not the only error. I was writing pseudo code. Real code
it's quite complex.
Try this one (is a
Am Fri, 01 Mar 2013 15:09:11 +0100
schrieb monarch_dodra monarchdo...@gmail.com:
On Friday, 1 March 2013 at 13:59:08 UTC, Johannes Pfau wrote:
When trying to implement non-POD types for gdc some time ago I
asked on
the dmd mailing list what the backend is actually supposed to
do for
Am Thu, 28 Feb 2013 14:33:15 -0800 (PST)
schrieb Brad Roberts bra...@puremagic.com:
On Thu, 28 Feb 2013, Simen Kj?r?s wrote:
On Thu, 28 Feb 2013 16:22:49 +0100, D-ratiseur
thisadressdoesntex...@nowhere.fr wrote:
Hello, Is it possible for an ASM function to be inlined in D?
Nope.
Andrea Fontana:
How to put s1,s2,3... in a range/array or something
similar/iterable? Probably there's no way (inside variant?)...
One solution is to not use templates:
immutable struct Weights {
double foo, bar;
}
enum Weights firstWeights = { foo: 0.3, bar: 0.4 },
void main() {
immutable s1 = MyStruct(firstWeights, 10, 8);
immutable s2 = MyStruct(firstWeights, 9, 10);
immutable s3 = MyStruct(secondWeights, 9, 10);
import std.stdio;
writeln(likeness(s1, s2));
Sorry for the mix of tabs and spaces. The crappy
On Friday, 1 March 2013 at 15:08:21 UTC, bearophile wrote:
void main() {
immutable s1 = MyStruct(firstWeights, 10, 8);
immutable s2 = MyStruct(firstWeights, 9, 10);
immutable s3 = MyStruct(secondWeights, 9, 10);
import std.stdio;
writeln(likeness(s1,
Andrea Fontana:
BTW, compiler can't guess s1 and s2 weights, should it?
if inside likeness() i write:
enum test = first.weights.foo * second.weights.foo;
it said that can't read first and second value at compile time.
firstWeights and secondWeights are compile-time constants, but
the
On Friday, 1 March 2013 at 16:03:58 UTC, bearophile wrote:
Andrea Fontana:
BTW, compiler can't guess s1 and s2 weights, should it?
if inside likeness() i write:
enum test = first.weights.foo * second.weights.foo;
it said that can't read first and second value at compile time.
firstWeights
Andrea Fontana:
but:
enum s1 = MyStruct(firstWeights, 10, 8);
enum s2 = MyStruct(firstWeights, 9, 10);
writeln(likeness(s1, s2));
still gives error: and s1 and s2 are known at compile time,
aren't them?
Right. But they are known at compile-time only outside likeness().
Your
On Friday, 1 March 2013 at 14:32:12 UTC, Andrea Fontana wrote:
struct MyStruct(WEIGHTS)
{
string ...
string ...
alias WEIGHTS weights;
}
enum FirstWeights : double
{
}
enum SecondWeights : double
{
double foo = 0.3,
double bar = 0.4
}
so:
auto s1 = MyStruct!FirstWeights
On Friday, 1 March 2013 at 16:38:39 UTC, Era Scarecrow wrote:
On Friday, 1 March 2013 at 14:32:12 UTC, Andrea Fontana wrote:
struct MyStruct(WEIGHTS)
{
string ...
string ...
alias WEIGHTS weights;
}
enum FirstWeights : double
{
}
enum SecondWeights : double
{
double foo = 0.3,
I am making a program which accesses 1D array using for loop and
then I am parallelizing this with foreach, TaskPool and parallel.
The array does not need to change, once initialized. However, the
parallel version takes more time than serial version, which I
think may be because compiler is
On Friday, 1 March 2013 at 20:05:41 UTC, Sparsh Mittal wrote:
I am making a program which accesses 1D array using for loop
and then I am parallelizing this with foreach, TaskPool and
parallel.
The array does not need to change, once initialized. However,
the parallel version takes more time
Array is really big!
import std.stdio;
import std.datetime;
import std.parallelism;
import std.range;
//int numberOfWorkers = 2; //for parallel;
double my_abs(double n) { return n 0 ? n : -n; }
immutable long DIM = 1024L*1024L *128L;
void main()
{
double[] signal = new double[DIM+1];
I suppose this:
immutable long DIM = 1024L*1024L *128L;
immutable(double)[] signal = new double[DIM+1];
static this() {
for (long i=0L; i DIM+1; i++) {
signal[i] = (i+DIM)%7 + (i+DIM+1)%5;
}
}
void main()
{ ... }
Sparsh Mittal:
So, is there a way, an array can be made immutable and still
initialized? Thanks a lot for your time.
There are various ways to do it. One of the safest way to do it
is to create a mutable array inside a strongly pure function, and
then when you return it assign it to
foreach (immutable i; 0 .. DIM + 1) {
Thanks. However, rdmd gives error on this line:
temp1.d(12): Error: no identifier for declarator immutable(i)
On Friday, 1 March 2013 at 20:28:19 UTC, FG wrote:
I suppose this:
immutable long DIM = 1024L*1024L *128L;
immutable(double)[] signal = new double[DIM+1];
static this() {
for (long i=0L; i DIM+1; i++) {
signal[i] = (i+DIM)%7 + (i+DIM+1)%5;
}
}
void main()
{ ... }
Thanks. This
Removing immutable word solves the problem. Thanks.
I realized that access to temp causes bottleneck. On defining
it inside for loop, it become local and then there is speedup.
Defining it outside makes it shared, which slows the program.
Sparsh Mittal:
Thanks. However, rdmd gives error on this line:
temp1.d(12): Error: no identifier for declarator immutable(i)
Probably v.2.062 of the D compiler is enough to not see that
error.
Bye,
bearophile
On 2013-03-01 22:05, Sparsh Mittal wrote:
On Friday, 1 March 2013 at 20:28:19 UTC, FG wrote:
I suppose this:
immutable long DIM = 1024L*1024L *128L;
immutable(double)[] signal = new double[DIM+1];
static this() {
for (long i=0L; i DIM+1; i++) {
signal[i] = (i+DIM)%7 + (i+DIM+1)%5;
Here is a code:
import std.stdio, std.datetime, std.random, std.range,
std.parallelism;
enum long numberOfSlaves = 2;
void myFunc( ref long countvar)
{
countvar = 500;
writeln( value of countvar is , countvar);
}
void main()
{
long count1=0, count2=0;
alias
In my case, the problem had to do with the order in which I was
linking my static libs, simply changing the order resolved the
undefined references. Turns out it's a common problem when
working with static libs and it's unrelated to D.
--rt
On Sat, Mar 02, 2013 at 04:17:10AM +0100, Rob T wrote:
In my case, the problem had to do with the order in which I was
linking my static libs, simply changing the order resolved the
undefined references. Turns out it's a common problem when working
with static libs and it's unrelated to D.
On 03/01/2013 06:51 PM, Sparsh Mittal wrote:
Possibility 1: Here, I wanted to pass a value by reference to myFunc,
but when I read that value in main function, its value is not changed at
all?
This is a known issue and is documented in the std.parallelism module:
38 matches
Mail list logo
