Re: Safely writing to the same file in parallel foreach loop

2012-11-14 Thread Joseph Rushton Wakeling
On 11/15/2012 12:44 AM, Joseph Rushton Wakeling wrote: In the application I have in mind, there is a LOT of work that would be done within the parallel foreach loop -- we're talking at least 20 minutes' solid processing before the file write takes place, so this seems an appropriate approach give

Some stuff about unittests, contracts, etc

2012-11-14 Thread bearophile
http://www.reddit.com/r/programming/comments/137kqg/static_typing_contracts_and_unit_tests/# Bye, bearophile

Re: Safely writing to the same file in parallel foreach loop

2012-11-14 Thread Joseph Rushton Wakeling
On 11/14/2012 10:17 PM, Jonathan M Davis wrote: I would point out though that given how expensive disk writes are, unless you're doing a lot of work within the parallel foreach loop, there's a good chance that it would be more efficient to use std.concurrency and pass the writes to another thread

Re: Safely writing to the same file in parallel foreach loop

2012-11-14 Thread Jonathan M Davis
On Wednesday, November 14, 2012 18:59:29 Joseph Rushton Wakeling wrote: > On 11/14/2012 06:49 PM, Vijay Nayar wrote: > > Could you put the file access in a synchronized block? > > > > http://dlang.org/statement.html#SynchronizedStatement > > Oh, good call -- seems to work. I would point out thou

Re: funky property error with assoc array

2012-11-14 Thread Jonathan M Davis
On Wednesday, November 14, 2012 20:48:57 Dan wrote: > This fails to compile when accessing as m.pgoo() complaining > about postblit. > What is wrong with this? > > Note: If I alias as array instead of map: alias const(X)[] Map; > it compiles fine. > > Thanks > Dan > -

Re: taskPool.map using functions with more than one input

2012-11-14 Thread Jonathan M Davis
On Wednesday, November 14, 2012 18:31:07 Joseph Rushton Wakeling wrote: > Is it possible to use taskPool.map with functions that take more than one > input? > > Consider the following code which uses map to convert a given value to its > sum with another number: > > import std.algorithm, std.para

funky property error with assoc array

2012-11-14 Thread Dan
This fails to compile when accessing as m.pgoo() complaining about postblit. What is wrong with this? Note: If I alias as array instead of map: alias const(X)[] Map; it compiles fine. Thanks Dan - struct X { this(this) {} } alias const(X)[string] Map; @property int pg

funky property error with assoc array

2012-11-14 Thread Dan
This fails to compile when accessing as m.pgoo() complaining about postblit. What is wrong with this? Note: If I alias as array instead of map: alias const(X)[] Map; it compiles fine. Thanks Dan - struct X { this(this) {} } alias const(X)[string] Map; @property int pg

funky property error with assoc array

2012-11-14 Thread Dan
This fails to compile when accessing as m.pgoo() complaining about postblit. What is wrong with this? Note: If I alias as array instead of map: alias const(X)[] Map; it compiles fine. Thanks Dan - struct X { this(this) {} } alias const(X)[string] Map; @property int p

Re: Safely writing to the same file in parallel foreach loop

2012-11-14 Thread Vijay Nayar
I think this is what you want around the file access section: http://dlang.org/statement.html#SynchronizedStatement - Vijay On Wednesday, 14 November 2012 at 16:43:37 UTC, Joseph Rushton Wakeling wrote: I take it there's no more "native-to-D" way of implementing a file lock? :-(

Re: Safely writing to the same file in parallel foreach loop

2012-11-14 Thread Joseph Rushton Wakeling
On 11/14/2012 06:49 PM, Vijay Nayar wrote: Could you put the file access in a synchronized block? http://dlang.org/statement.html#SynchronizedStatement Oh, good call -- seems to work. If you try and run the parallel code without it, there's a pretty nasty-looking error: /tmp/.rdmd-1000/

Re: Safely writing to the same file in parallel foreach loop

2012-11-14 Thread Vijay Nayar
On Wednesday, 14 November 2012 at 16:43:37 UTC, Joseph Rushton Wakeling wrote: On 11/14/2012 05:16 PM, H. S. Teoh wrote: I take it there's no more "native-to-D" way of implementing a file lock? :-( Could you put the file access in a synchronized block? http://dlang.org/statement.html#Synchron

Re: Safely writing to the same file in parallel foreach loop

2012-11-14 Thread Vijay Nayar
On Wednesday, 14 November 2012 at 16:43:37 UTC, Joseph Rushton Wakeling wrote: On 11/14/2012 05:16 PM, H. S. Teoh wrote: I take it there's no more "native-to-D" way of implementing a file lock? :-( Could you put the file access in a synchronized block? http://dlang.org/statement.html#Synchron

taskPool.map using functions with more than one input

2012-11-14 Thread Joseph Rushton Wakeling
Is it possible to use taskPool.map with functions that take more than one input? Consider the following code which uses map to convert a given value to its sum with another number: import std.algorithm, std.parallelism, std.range, std.stdio; real pairsum(real x, real y) {

Re: Is Override Still Mandatory?

2012-11-14 Thread Rob T
On Wednesday, 14 November 2012 at 08:04:55 UTC, Jonathan M Davis wrote: but I'm one of the Phobos developers. It's fine if you use master (it could help us find regressions if nothing else), but I wouldn't really advise using it just to be able to use the -di flag. There have been a few ot

Re: Safely writing to the same file in parallel foreach loop

2012-11-14 Thread Joseph Rushton Wakeling
On 11/14/2012 05:16 PM, H. S. Teoh wrote: If you're on Posix, you can use file locks to ensure atomic writes to the file (all threads have to use it though: it's only an advisory lock, not a mandatory lock): see the manpage for fcntl, look for F_GETLK. I take it there's no more "native-to-D" wa

Re: Coverting ubyte to string.

2012-11-14 Thread Vijay Nayar
This might help. import std.c.string; void main() { // The input data: ubyte* ustr = cast(ubyte*) "bobcat\0".ptr; // Conversion to 'string'. char* cstr = cast(char*) ustr; string str = cast(string) cstr[0..strlen(cstr)]; assert(str == "bobcat"); } - Vijay On Wednesday, 14 Novembe

Re: Safely writing to the same file in parallel foreach loop

2012-11-14 Thread H. S. Teoh
On Wed, Nov 14, 2012 at 04:56:53PM +0100, Joseph Rushton Wakeling wrote: > Suppose that I've got a foreach loop in which I write output to a file: > > auto f = File("test.txt", "w"); f.close(); // to start with a blank file > foreach(i; iota(0, 100)) > { > f = File("test.txt",

Safely writing to the same file in parallel foreach loop

2012-11-14 Thread Joseph Rushton Wakeling
Suppose that I've got a foreach loop in which I write output to a file: auto f = File("test.txt", "w"); f.close(); // to start with a blank file foreach(i; iota(0, 100)) { f = File("test.txt", "a"); f.writeln(i); f.close(); } I'm guessing it is at least p

Re: Coverting ubyte to string.

2012-11-14 Thread simendsjo
On Wednesday, 14 November 2012 at 13:37:26 UTC, Knud Soerensen wrote: Hi I am working with a c library which return a unsigned char * As suggested on http://digitalmars.com/d/1.0/htomodule.html I have converted it to (ubyte *). Now is there an easy way to convert this to a string ? import s

Re: Inferring function argument types from other argument types

2012-11-14 Thread Joseph Rushton Wakeling
On 11/13/2012 06:47 PM, Ali Çehreli wrote: Still, please create a bug report: :) Done :-) http://d.puremagic.com/issues/show_bug.cgi?id=9024

Coverting ubyte to string.

2012-11-14 Thread Knud Soerensen
Hi I am working with a c library which return a unsigned char * As suggested on http://digitalmars.com/d/1.0/htomodule.html I have converted it to (ubyte *). Now is there an easy way to convert this to a string ? Knud

Re: operations on rectangular arrays

2012-11-14 Thread bearophile
dominic jones: Is there a succinct work-around (i.e. without using foreach)? 2D built-in array operations are not supported. APL-style orthogonality isn't at home in D, it seems. Bye, bearophile

operations on rectangular arrays

2012-11-14 Thread dominic jones
Hello, This code snippet: int[][] A = [[1, 2], [2, 3]]; int[][] B = [[2, 3], [1, 2]]; int[2][2] C; C = A[][] + B[][]; fails with the message: "Error: cannot implicitly convert expression (A[][] + B[][]) of type int[][] to int[2LU][]" Is there a succinct work-around (i.e. without usi

Re: Shared value types can not be destructed

2012-11-14 Thread Benjamin Thaut
Am 13.11.2012 17:25, schrieb Benjamin Thaut: Apperently this is by design: http://d.puremagic.com/issues/show_bug.cgi?id=8295 To clarify: It is not possible to define a destructor that will be called on the destruction of a shared struct. In a different thread Walter commeted this bug with: "If

Re: Is Override Still Mandatory?

2012-11-14 Thread Jonathan M Davis
On Wednesday, November 14, 2012 07:59:06 Rob T wrote: > That's good news. If I were to use the latest pre-release version > of dmd that was relatively safe, how will I find it, or is it OK > to use the master branch? The master branch _is_ the pre-release version. dmd, druntime, and Phobos do not