Re: Multiple while-loops parallelism
On 01/17/2014 01:28 PM, Kelet wrote:
> create a Task[2]. Once the Task is created, use the executeInNewThread
> function. You can use yieldForce to wait on it.
That's what I thought initially as well but then I realized that it can
be even simpler than that:
import std.stdio;
import std.parallelism;
void main()
{
// All of these loops can be free-standing functions as well
long sum1 = 0;
auto loop1 = {
foreach (number; 0 .. 100) {
sum1 += number;
}
};
long sum2 = 0;
auto loop2 = {
foreach (number; 0 .. 100) {
sum2 += number;
}
};
foreach (loop; [ loop1, loop2 ].parallel) {
loop();
}
writefln("sum1: %s, sum2: %s", sum1, sum2);
}
Ali
Re: errors with filesystem operations
On Fri, 17 Jan 2014 13:10:00 +, Kagamin wrote: I only noticed that rename uses MOVEFILE_REPLACE_EXISTING flag, which can't be used with directories. Are you sure remove fails too? If rename throws, remove is not called in your code. Well, as a matter of fact I did try to use remove directly and it failed with the same problem (directory in use by some process) Since subdirectories were being moved just fine, I thought once the content of the problematic directory was moved elsewhere I could rename the directory first and then remove it, but this approach failed too, at least from Windows.
Re: Is it possible to store properties via opDispatch using tuples?
On 2014-01-17 22:14, H. S. Teoh wrote: Is that because D doesn't have implicit casting via opCast? -- because, conceivably, if x = d.abc; gets lowered to x = d.opCast!(typeof(x))(d.abc); then the above can be made to work. I don't know, maybe. -- /Jacob Carlborg
Re: Multiple while-loops parallelism
On Friday, 17 January 2014 at 21:07:46 UTC, Mineko wrote: Today I'm asking a more theoretical question, since I can't quite grasp this one too well. Let's say I want 3 while-loops running in parallel, without getting in the way of each other, how would I do that? With std.parallel of course, but that's where I get confused, perhaps someone could enlighten me? Hi, std.parallel You mean std.parallelism. Assuming your code is thread safe[1], you would have each of these while loops in a delegate or function, and create a Task[2]. Once the Task is created, use the executeInNewThread function. You can use yieldForce to wait on it. However, if you don't *really* need while loops, take a look at creating a TaskPool and using a parallel foreach, reduce, map, etc. They are also in std.parallelism. However, it's worth noting that there is also std.concurrency[3] which may be a better approach if your threads need to communicate. core.thread/core.atomic are useful if you need lower level control. If your code is not thread safe, look into synchronized statement, core.atomic, and possibly core.sync.* and make it thread safe. [1]: http://en.wikipedia.org/wiki/Thread_safety [2]: http://dlang.org/phobos/std_parallelism.html#.Task [3]: http://dlang.org/phobos/std_concurrency.html Regards, Kelet
Re: Is it possible to store properties via opDispatch using tuples?
On Fri, Jan 17, 2014 at 09:08:50PM +0100, Jacob Carlborg wrote: > On 2014-01-17 18:49, H. S. Teoh wrote: > > >Now I'm not sure if Variant allows assignment to a static type, but > >in theory this should be possible: > > > > // assume d.abc returns a Variant > > int x = d.abc; // will assert if d.abc doesn't hold an int at runtime > > It doesn't work. Variant doesn't retain the static type, which is > needed in this case. [...] Is that because D doesn't have implicit casting via opCast? -- because, conceivably, if x = d.abc; gets lowered to x = d.opCast!(typeof(x))(d.abc); then the above can be made to work. T -- If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton
Re: Multiple while-loops parallelism
On Friday, 17 January 2014 at 21:07:46 UTC, Mineko wrote: Let's say I want 3 while-loops running in parallel, without getting in the way of each other, how would I do that? On the same set of data? That's optimistic if one of the loops writes :) Otherwise, you could just create three tasks, one per loop.
Multiple while-loops parallelism
Today I'm asking a more theoretical question, since I can't quite grasp this one too well. Let's say I want 3 while-loops running in parallel, without getting in the way of each other, how would I do that? With std.parallel of course, but that's where I get confused, perhaps someone could enlighten me?
Re: Is it possible to store properties via opDispatch using tuples?
On 2014-01-17 18:49, H. S. Teoh wrote: Now I'm not sure if Variant allows assignment to a static type, but in theory this should be possible: // assume d.abc returns a Variant int x = d.abc; // will assert if d.abc doesn't hold an int at runtime It doesn't work. Variant doesn't retain the static type, which is needed in this case. -- /Jacob Carlborg
Re: package.d imports
I think this is what you are looking for: http://dlang.org/changelog.html#import_package What an odd place to put it.. Too bad, it doesn't mention anything about calling the functions like in my example, and why some do/don't work. I'd hoped for more.
Re: Is it possible to store properties via opDispatch using tuples?
On Fri, Jan 17, 2014 at 07:08:54PM +, Tobias Pankrath wrote:
> >I can store properties of type A, B and C but when i retrieve them
> >they all come back as A because of array covariance. I wonder if
> >there is a way of casting them automagically to the correct type.
>
> So you basically want to declare a classmember for every name
> opDispatch is called with? That is not possible;
>
> I thought about declaring it static in opDispatch itself, but than
> you can only have one instance. Next thought: Declare a static
> hashmap and store the values there, but then you could just use
> std.variant.
One of the reasons this breaks down is because of situations like this:
class MyClass {
...
auto opDispatch(string op)() {
return ... /* assume we magically return the right type
here */;
}
}
// Which of these assignments to 'abc' should determine its
// type? What if the function that gets called is determined at
// runtime only? What if they are in two separately-compiled
// modules?
void fun(MyClass o) {
o.abc = 123;
}
void gun(MyClass o) {
o.abc = "xyz";
}
auto x = o.abc; // what's the type of x?
Another problematic case:
auto o = new MyClass;
auto p = new MyClass;
o.abc = 123;
p.abc = "xyz";
// Problem: now the return type of opDispatch cannot be
// determined at compile-time.
Now, if you decide beforehand that "abc" is always an int, and "def" is
always a string, then this problem is avoided:
o.abc = 123; // OK
p.abc = 123; // OK
o.abc = "xyz"; // compile error
p.abc = "xyz"; // compile error
o.def = "xyz"; // OK
p.def = "xyz"; // OK
o.def = 123; // compile error
p.def = 123; // compile error
T
--
Freedom of speech: the whole world has no right *not* to hear my spouting off!
Re: Is it possible to store properties via opDispatch using tuples?
On Fri, Jan 17, 2014 at 06:49:25PM +, Gary Willoughby wrote:
[...]
> In the example in my original post the types are known at compile
> time but they are different between properties. I wondered if there
> was a solution to storing and retrieving while preserving the
> original type via opDispatch.
>
> I have a working solution but it only stores the base type. So i f i
> have an inheritance chain like this:
>
> A -> B -> C
>
> I can store properties of type A, B and C but when i retrieve them
> they all come back as A because of array covariance. I wonder if
> there is a way of casting them automagically to the correct type.
Is it possible, at compile-time, to determine the type just from the
property name alone? If not (i.e., different class instances may have a
property named "abc" map to int or string, respectively), then this is
not possible, because the return type of opDispatch can only depend on
its compile-time parameter, that is, the property name.
If there's a compile-time procedure for determining the type of a
property solely from its name, then yes, this is possible. What you do
is to first determine the return type from the property name (at
compile-time!), hash the .mangleof of this type, and store an AA of AA's
of property values, with the outer AA keyed by the hash value.
Something like this:
class MyClass {
Variant[string][size_t] props;
auto opDispatch(string ident)() {
alias returnType = ... /* determine type from ident */;
enum id = hashOf(T.mangleof); // unique ID for T
return cast(returnType)props[id][ident];
}
}
The success of this depends on whether it's possible to determine the
return type from the property name (at compile-time), though. If that's
not possible, then this doesn't work.
T
--
Acid falls with the rain; with love comes the pain.
Re: Is it possible to store properties via opDispatch using tuples?
I can store properties of type A, B and C but when i retrieve them they all come back as A because of array covariance. I wonder if there is a way of casting them automagically to the correct type. So you basically want to declare a classmember for every name opDispatch is called with? That is not possible; I thought about declaring it static in opDispatch itself, but than you can only have one instance. Next thought: Declare a static hashmap and store the values there, but then you could just use std.variant.
Re: Is continuously seeding a random number generator performance intensive?
On Wednesday, 15 January 2014 at 21:00:57 UTC, Jeroen Bollen wrote: How do you correctly create a MersenneTwisterEngine with a ulong as seed? This question still isn't answered by the way.
Re: Is it possible to store properties via opDispatch using tuples?
On Friday, 17 January 2014 at 17:50:54 UTC, H. S. Teoh wrote:
On Fri, Jan 17, 2014 at 05:29:14PM +, Gary Willoughby wrote:
On Friday, 17 January 2014 at 15:56:46 UTC, H. S. Teoh wrote:
>Couldn't you just return a Variant? I thought this is what
>Variants
>are made for.
>
>
>T
Yes but then i would need to coerce it to get it's underlying
type.
But isn't that what you'd have to do anyway? I mean, how else
would the
following code work?
class DynClass {
...
auto opDispatch(string field)() {
return dotDotDotMagic();
}
}
void main(string[] args) {
auto d = new DynClass();
if (args[1] == "int")
d.abc = 123; // d.abc = int
else
d.abc = "xyz"; // d.abc = string
// Suppose this somehow works:
auto x = d.abc; // what's the type of x?
}
Since the type of x must be known at compile-time, but the type
of d.abc
can't be known until runtime, the above code can't possibly
work unless
d.abc returns a Variant. It's simply not possible for a
runtime-determined type to be put into a variable of
compile-time
determined type without some kind of runtime check.
Now I'm not sure if Variant allows assignment to a static type,
but in
theory this should be possible:
// assume d.abc returns a Variant
int x = d.abc; // will assert if d.abc doesn't hold an int at
runtime
T
In the example in my original post the types are known at compile
time but they are different between properties. I wondered if
there was a solution to storing and retrieving while preserving
the original type via opDispatch.
I have a working solution but it only stores the base type. So i
f i have an inheritance chain like this:
A -> B -> C
I can store properties of type A, B and C but when i retrieve
them they all come back as A because of array covariance. I
wonder if there is a way of casting them automagically to the
correct type.
Re: Is it possible to store properties via opDispatch using tuples?
On Fri, Jan 17, 2014 at 05:29:14PM +, Gary Willoughby wrote:
> On Friday, 17 January 2014 at 15:56:46 UTC, H. S. Teoh wrote:
> >Couldn't you just return a Variant? I thought this is what Variants
> >are made for.
> >
> >
> >T
>
> Yes but then i would need to coerce it to get it's underlying type.
But isn't that what you'd have to do anyway? I mean, how else would the
following code work?
class DynClass {
...
auto opDispatch(string field)() {
return dotDotDotMagic();
}
}
void main(string[] args) {
auto d = new DynClass();
if (args[1] == "int")
d.abc = 123; // d.abc = int
else
d.abc = "xyz"; // d.abc = string
// Suppose this somehow works:
auto x = d.abc; // what's the type of x?
}
Since the type of x must be known at compile-time, but the type of d.abc
can't be known until runtime, the above code can't possibly work unless
d.abc returns a Variant. It's simply not possible for a
runtime-determined type to be put into a variable of compile-time
determined type without some kind of runtime check.
Now I'm not sure if Variant allows assignment to a static type, but in
theory this should be possible:
// assume d.abc returns a Variant
int x = d.abc; // will assert if d.abc doesn't hold an int at runtime
T
--
There are 10 kinds of people in the world: those who can count in binary, and
those who can't.
Re: Is it possible to store properties via opDispatch using tuples?
On Friday, 17 January 2014 at 15:56:46 UTC, H. S. Teoh wrote: Couldn't you just return a Variant? I thought this is what Variants are made for. T Yes but then i would need to coerce it to get it's underlying type.
Re: package.d imports
On Thursday, 16 January 2014 at 15:46:01 UTC, Lemonfiend wrote:
The following behavior seems odd to me. Could anyone explain
why it works as it does? (Does package.d have a page on
dlang.org?)
--- main.d
module main;
void main()
{
test1();
test2();
}
void test1()
{
import pack;
// works
foo();
// works, did not expect it to
pack.foo();
// does not work: Error: undefined identifier 'sub'
//pack.sub.foo();
}
void test2()
{
import pack.sub;
// works
foo();
// works, even more unexpectedly
pack.foo();
// works
pack.sub.foo();
}
--- package/pack.d
module pack;
public import pack.sub;
--- package/sub.d
module pack.sub;
void foo()
{
import std.stdio;
writeln("hello");
}
I think this is what you are looking for:
http://dlang.org/changelog.html#import_package
Re: std.prelude vs core library
Another small reason is to enforce decoupling between required code and the rest of the library. Back when Phobos was all one library, half the library was compiled into every program. The runtime writes to stderr, the IO package relies on other modules... Kind of like what happens now if you import std.stdio. And while this can be accomplished via deliberate effort towards decoupling. But that's really hard to accomplish in an open source project. Functionally, think of core as being similar to java.lang.
Re: Is it possible to store properties via opDispatch using tuples?
On Fri, Jan 17, 2014 at 08:56:18AM +0100, Jacob Carlborg wrote:
> On 2014-01-16 21:26, Gary Willoughby wrote:
> >What i would like to achieve is to dynamically assign and retrieve
> >properties without declaring them first. For example:
> >
> >class T
> >{
> > public this()
> > {
> > this.foo = "bar";
> > }
> >}
> >
> >Ordinarily the above won't compile because 'foo' hasn't been declared
> >but with opDispatch i can handle this. The problem is how do i handle
> >different types of each property.
> >
> >I was thinking about something like this:
> >
> >class A
> >{
> >}
> >
> >class B : A
> >{
> >}
> >
> >class C : B
> >{
> >}
> >
> >class T
> >{
> > private Tuple[string] _properties;
> >
> > public this()
> > {
> > this.a = new A();
> > this.b = new B();
> > this.c = new C();
> > }
> >
> > public void opDispatch(string name, T)(T element)
> > {
> > this._properties[name] = Tuple(T, element);
> > }
> >
> > public auto opDispatch(string name)()
> > {
> > if (name in this._properties)
> > {
> > return
> >cast(this._properties[name][0])this._properties[name][1];
> > }
> > }
> >}
> >
> >Of course this doesn't compile but is this actually possible? i.e.
> >storing the type and data. Then on retrieval returning the correct data
> >cast to the correct type? All done dynamically without any property
> >being pre-declared.
>
> I have no way of seeing this work. The problem is you need to
> somehow store the static type revived in opDispatch. But to store an
> unknown type as an instance variable you need to use a template
> class.
[...]
Couldn't you just return a Variant? I thought this is what Variants are
made for.
T
--
"The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts." -- Bertrand
Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
Re: thisExePath and rdmd
On 2014-01-17 15:29, Andrea Fontana wrote: I think it would be useful to put full path on __FILE__ or to add another constant. Anyone? I agree. Probably safest to add a new constant, to avoid breaking code. -- /Jacob Carlborg
Re: thisExePath and rdmd
On Friday, 17 January 2014 at 10:48:33 UTC, Jacob Carlborg wrote: On 2014-01-17 10:50, Andrea Fontana wrote: Hmm I thought It can be done reading __FILE__ at compile-time, but it gives me just the relative path. Right, forgot about __FILE__. I think it would be useful to put full path on __FILE__ or to add another constant. Anyone?
Re: errors with filesystem operations
I only noticed that rename uses MOVEFILE_REPLACE_EXISTING flag, which can't be used with directories. Are you sure remove fails too? If rename throws, remove is not called in your code.
Re: errors with filesystem operations
On Fri, 17 Jan 2014 07:07:35 +, Kagamin wrote: Does it fail for that one directory only or for any directory? Interesting question. I would have to do more tests with odd names, but apparently both remove() and rename() have problems with directories with a blank name. Curiously, moving files or directories from within that blank directory to another directory seems to working correctly, so it's not like the directory is not being detected. I haven't dived in the code for both functions, but I suspect that some validation may be causing the problem.
Re: Associative array literal is non-constant?
On Saturday, 4 February 2012 at 06:45:08 UTC, H. S. Teoh wrote: On Fri, Feb 03, 2012 at 10:18:18PM -0800, H. S. Teoh wrote: Why does the following code give a compiler error? static int[string] table = ["abc":1, "def":2, "ghi":3]; Error message is: prog.d:3: Error: non-constant expression ["abc":1,"def":2,"ghi":3] How is a literal non-constant? [...] Ugh. Just found this: http://d.puremagic.com/issues/show_bug.cgi?id=6238 Further testing shows that assoc array literals can't be used outside of function scope at all, for example: // (in package scope) auto hash = [ "abc":1, "def":2, "ghi":3 ]; // Error: non-constant expression ["abc":1,"def":2,"ghi":3] Seems like a pretty nasty bug to me. T I would just like to add a vote for using assoc array literals outside of function scope. They are a handy way to represent data, and often data needs to be defined in other scopes.
Re: thisExePath and rdmd
On 2014-01-17 10:50, Andrea Fontana wrote: Hmm I thought It can be done reading __FILE__ at compile-time, but it gives me just the relative path. Right, forgot about __FILE__. -- /Jacob Carlborg
Re: thisExePath and rdmd
Hmm I thought It can be done reading __FILE__ at compile-time, but it gives me just the relative path. Recent topic here: http://forum.dlang.org/thread/meuyppazxkrjcbgmk...@forum.dlang.org On Friday, 17 January 2014 at 09:29:48 UTC, Jacob Carlborg wrote: On 2014-01-17 10:23, Andrea Fontana wrote: thisExePath "returns the full path of the current executable". If I run something like "./mysource.d" (using rdmd shebang) it returns the full path to compiled executable in /tmp folder (not so useful I think!). Is there a way to have the path of source itself? That doesn't sound very easy to fix. When running the executable it's completely disconnected from the source file it was compiled from. Except for possibly some debug info.
Re: thisExePath and rdmd
On 2014-01-17 10:23, Andrea Fontana wrote: thisExePath "returns the full path of the current executable". If I run something like "./mysource.d" (using rdmd shebang) it returns the full path to compiled executable in /tmp folder (not so useful I think!). Is there a way to have the path of source itself? That doesn't sound very easy to fix. When running the executable it's completely disconnected from the source file it was compiled from. Except for possibly some debug info. -- /Jacob Carlborg
thisExePath and rdmd
thisExePath "returns the full path of the current executable". If I run something like "./mysource.d" (using rdmd shebang) it returns the full path to compiled executable in /tmp folder (not so useful I think!). Is there a way to have the path of source itself?
Re: Is it possible to store properties via opDispatch using tuples?
On 2014-01-16 21:26, Gary Willoughby wrote:
What i would like to achieve is to dynamically assign and retrieve
properties without declaring them first. For example:
class T
{
public this()
{
this.foo = "bar";
}
}
Ordinarily the above won't compile because 'foo' hasn't been declared
but with opDispatch i can handle this. The problem is how do i handle
different types of each property.
I was thinking about something like this:
class A
{
}
class B : A
{
}
class C : B
{
}
class T
{
private Tuple[string] _properties;
public this()
{
this.a = new A();
this.b = new B();
this.c = new C();
}
public void opDispatch(string name, T)(T element)
{
this._properties[name] = Tuple(T, element);
}
public auto opDispatch(string name)()
{
if (name in this._properties)
{
return
cast(this._properties[name][0])this._properties[name][1];
}
}
}
Of course this doesn't compile but is this actually possible? i.e.
storing the type and data. Then on retrieval returning the correct data
cast to the correct type? All done dynamically without any property
being pre-declared.
I have no way of seeing this work. The problem is you need to somehow
store the static type revived in opDispatch. But to store an unknown
type as an instance variable you need to use a template class.
--
/Jacob Carlborg
