Stride in foreach ranges
Is there a better way to express a range with stride than this: foreach (i; iota(0, N, 2)) Maybe something similar to F# syntax: foreach (i; 0..2..N) I found this thread suggesting syntax improvement http://forum.dlang.org/thread/bug-411...@http.d.puremagic.com/issues/ but I don't think it produced any results. BTW, DMD produces faster code when for loop is used instead, with GDC it makes no difference.
Re: UFCS in template function
On 2013-08-29 22:02, Andrej Mitrovic wrote:
However it does work for local imports (I think this was new in 2.063):
void main()
{
import std.range;
assert([].empty); // ok
}
empty is declared at module scope.
--
/Jacob Carlborg
Problem with rdmd
On Linux 64
$chmod +x htest
$cat ./htest
#!/usr/bin/env rdmd
import std.stdio;
void main() {
writeln(hello world!);
}
then:
$./htest
Error: cannot read file ./htest.d
Failed: 'dmd' '-v' '-o-' './htest.d' '-I.'
OTOH:
$cp htest htest.d
$./htest.d
hello world!
It seems that rdmd expects the script to bear the .d extension.
This is not a very good choice, at least when writing git helper
scripts.
For example, a $git command command would eventually try to
execute the executable (script):
$git-command
The problem is that that line expects git-command, not
git-command.d.
A workaround for this?
Thanks
Re: Problem with rdmd
On Friday, 30 August 2013 at 07:39:41 UTC, eles wrote:
On Linux 64
$chmod +x htest
$cat ./htest
#!/usr/bin/env rdmd
import std.stdio;
void main() {
writeln(hello world!);
}
then:
$./htest
Error: cannot read file ./htest.d
Failed: 'dmd' '-v' '-o-' './htest.d' '-I.'
OTOH:
$cp htest htest.d
$./htest.d
hello world!
It seems that rdmd expects the script to bear the .d extension.
This is not a very good choice
yup
[...]
A workaround for this?
ln htest htest.d
Re: Question about garbage collector
so second question : I would like to know if using destroy function will help enough gc when working in big memory and saving time.
Re: Checking if UFCS function exists for a specific type
On Thursday, 29 August 2013 at 21:10:41 UTC, Rory McGuire wrote:
On Thursday, 29 August 2013 at 21:06:04 UTC, Rory McGuire wrote:
Hi all,
I've got this little ctfe template function that checks if a
function called member with first argument T exists. Its for
checking if a type has a custom encoder.
bool hasUFCSmember(T, string member)() {
T v;
// would be nice if we could use ParameterTypeTuple to get
the first arg and check for exact type match
return __traits(compiles, mixin(member ~(v)));
}
forum posted when I hit tab. Meant to ask:
Is there a way to make sure that the compiler is not implicitly
casting T?
Currently it returns true for bool, enum, int etc... even if
the only function available is for an int.
I also have:
template hasUFCSmember(T, string member) {
enum hasUFCSmember = __traits(compiles, mixin(member
~(T.init)));
}
But it doesn't work for types such as string[string] because
T.init is null.
Any help will be greatly appreciated.
Thanks,
R
I suppose I can avoid the implicit casts for function lookup by
using Typedef.
Thanks,
R
Re: Problem with rdmd
On Friday, 30 August 2013 at 07:56:14 UTC, anonymous wrote: On Friday, 30 August 2013 at 07:39:41 UTC, eles wrote: A workaround for this? ln htest htest.d Thanks.
Re: Problem with rdmd
On 2013-08-30 09:39, eles wrote:
On Linux 64
$chmod +x htest
$cat ./htest
#!/usr/bin/env rdmd
import std.stdio;
void main() {
writeln(hello world!);
}
then:
$./htest
Error: cannot read file ./htest.d
Failed: 'dmd' '-v' '-o-' './htest.d' '-I.'
OTOH:
$cp htest htest.d
$./htest.d
hello world!
It seems that rdmd expects the script to bear the .d extension.
I'm pretty sure it's DMD that is the problem.
--
/Jacob Carlborg
Re: Code from a Rosetta Code Task
On 30-8-2013 0:40, H. S. Teoh wrote:
(...)
A far better implementation is to use std.range.recurrence:
uint fib(in uint n) pure nothrow {
return recurrence!((a,n) = a[n-2] + a[n-1])(1, 1)
.drop(n-1)
.front;
}
This implementation has linear time complexity and constant space
complexity (vs. exponential time complexity vs. linear space complexity
in the original).
To illustrate how bad it is, I wrote a program that calls fib(50) for
each of the above implementations, and observed how long it takes each
one to return an answer. The version using recurrence completes in a
fraction of a second, the second takes two *minutes*. I bumped it up to
fib(100), and the recurrence version still runs under a fraction of a
second, but I ran out of patience waiting for the second one.
(...)
http://www.wolframalpha.com/input/?i=fib(100)
void main() {
import std.bigint, std.range;
BigInt fib(in uint fibN) pure {
return recurrence!((a,n) = a[n-2] + a[n-1])(BigInt(1), BigInt(1))
.drop(fibN-1)
.front;
}
assert(fib(100) == BigInt(354_224_848_179_261_915_075));
}
nice
Problem compiling Vibe.d First step
Hello, I'm trying to compile and run the Vibe.d First Step example [http://vibed.org/docs#first-steps] but I have unresolved libraries error from the linker : Linking... /usr/bin/ld: ne peut trouver -levent /usr/bin/ld: ne peut trouver -levent_pthreads /usr/bin/ld: ne peut trouver -lssl /usr/bin/ld: ne peut trouver -lcrypto On the vibe.d web page I don't see any dependency information and which version of these libraries are required. Where can I find this information ? I don't even know how to determine the vibe.d version my code is compiled against.
Re: Problem compiling Vibe.d First step
On Friday, 30 August 2013 at 12:51:16 UTC, chmike wrote: Does it expect 32bit library versions ? It may happen if you use 32-but dmd (or it is set to use -m32 in dmd.conf)
Re: Problem compiling Vibe.d First step
/usr/bin/ld: ne peut trouver -levent /usr/bin/ld: ne peut trouver -levent_pthreads /usr/bin/ld: ne peut trouver -lssl /usr/bin/ld: ne peut trouver -lcrypto All four libraries (amd64) are installed, at least libevent, libevent_pthreads and libssl. Does it expect 32bit library versions ?
Re: Problem compiling Vibe.d First step
On Friday, 30 August 2013 at 12:45:22 UTC, chmike wrote: Hello, I'm trying to compile and run the Vibe.d First Step example [http://vibed.org/docs#first-steps] but I have unresolved libraries error from the linker : Linking... /usr/bin/ld: ne peut trouver -levent /usr/bin/ld: ne peut trouver -levent_pthreads /usr/bin/ld: ne peut trouver -lssl /usr/bin/ld: ne peut trouver -lcrypto On the vibe.d web page I don't see any dependency information and which version of these libraries are required. Where can I find this information ? I don't even know how to determine the vibe.d version my code is compiled against. A bit more detailed manual setup is documented in vibe.d github repository manual : https://github.com/rejectedsoftware/vibe.d Most likely, you need to install libevent and openssl to fix linking errors. What is the way you have installed vibe.d with? `dub` package manager is usually considered default and most user-friendly approach and it should take care of dependencies. There is also an AUR package for Arch Linux (don't know about other distros)
Template overload causing an error even when a better non-template match is found
You're going to need DMD git-head to run this reduced example:
-
struct S
{
void opAssign(T)(T t)
if (Constraint!T)
{
}
void opAssign(typeof(null))
{
}
template Constraint(T)
if (is(T == int))
{
enum bool Constraint = false;
}
}
void main()
{
S s;
s = null;
}
-
This fails with:
test.d(6): Error: template instance Constraint!(typeof(null)) does not
match template declaration Constraint(T) if (is(T == int))
However I don't think the compiler should even attempt to instantiate
the template when there's a better non-template overload match.
The code example is contrived, but in the real code there's several
overloads of Constraint which do more sophisticated checking on
their type (some work on functions, others on delegates, structs,
classes, etc).
Hence why the constraint templates themselves need to have
constraints, but this is then causing the above error.
I'm not looking for a workaround (there's plenty of ways to work
around this), but I think this should be filed as a bug?
Re: Template overload causing an error even when a better non-template match is found
On 8/30/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
I'm not looking for a workaround (there's plenty of ways to work
around this)
Here's one way:
void opAssign(T)(T t)
if (is(typeof(Constraint!T)) Constraint!T)
{
pragma(msg, T);
}
void opAssign(T)(T t)
if (is(T == typeof(null)))
{
pragma(msg, null);
}
Re: Template overload causing an error even when a better non-template match is found
On 8/30/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 8/30/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
I'm not looking for a workaround (there's plenty of ways to work
around this)
Here's one way:
Sorry, better version, the second function doesn't need to be a
template (in git-head anyway):
void opAssign(T)(T t)
if (is(typeof(Constraint!T)) Constraint!T)
{
pragma(msg, T);
}
void opAssign(typeof(null))
{
pragma(msg, null);
}
Re: Problem with rdmd
On Friday, 30 August 2013 at 11:34:59 UTC, Jacob Carlborg wrote: On 2013-08-30 09:39, eles wrote: I'm pretty sure it's DMD that is the problem. Yes. But that's, the least to say, limiting. This: https://github.com/D-Programming-Language/tools/blob/master/rdmd.d#L160 should be solved in other manner. Maybe creating a temporary copy. Or forcing dmd in some ways. Besides, for what reasons dmd would impose a .d extension?
Re: Regarding emplace, arrays, and helper functions
On 8/30/13, Ali Çehreli acehr...@yahoo.com wrote: Now your program works with a single change: enum Size = paddedSize!C(); Excellent. However will the compiler align all static arrays so their memory begins at a proper offset? Maybe a more appropriate question is: Is all stack data guaranteed to be properly aligned, and on all platforms? For example: enum Size = paddedSize!C; ubyte[1] preBuffer; ubyte[Size][2] buffer; Is 'buffer' guaranteed to be aligned so its memory begins at a good offset? There could be any number of bytes before 'buffer', such as the preBuffer above it. Tests show that they are indeed aligned, but I wonder if this is something you can guarantee on all platforms?
Re: Stride in foreach ranges
On Friday, 30 August 2013 at 06:31:39 UTC, Paul Jurczak wrote: Is there a better way to express a range with stride than this: foreach (i; iota(0, N, 2)) Maybe something similar to F# syntax: foreach (i; 0..2..N) I found this thread suggesting syntax improvement http://forum.dlang.org/thread/bug-411...@http.d.puremagic.com/issues/ but I don't think it produced any results. BTW, DMD produces faster code when for loop is used instead, with GDC it makes no difference. That is strange because the FAQ says here: http://dlang.org/faq.html#foreach [...]let the compiler do the optimization. and Let the compiler pick! Can you prove this on DPaste?
Re: Stride in foreach ranges
On Friday, 30 August 2013 at 06:31:39 UTC, Paul Jurczak wrote: BTW, DMD produces faster code when for loop is used instead, with GDC it makes no difference. This pretty much shows that there is nothing wrong in language with current iota approach and it is simply problem of bad dmd code generation.
Re: Regarding emplace, arrays, and helper functions
I hate this magic library fix.. Why cannot we use 'scope' for this? I know currently it is an unsafe feature that was also proposed for rejection, but it would look better, feel better, and the compiler could take the dirty work for us. And maybe better optimized.
Re: Regarding emplace, arrays, and helper functions
On 8/30/13, Namespace rswhi...@googlemail.com wrote: I hate this magic library fix.. Why cannot we use 'scope' for this? I know currently it is an unsafe feature that was also proposed for rejection, but it would look better, feel better, and the compiler could take the dirty work for us. And maybe better optimized. It would also avoid this nasty issue: http://d.puremagic.com/issues/show_bug.cgi?id=10921
Re: Regarding emplace, arrays, and helper functions
On Friday, 30 August 2013 at 14:45:40 UTC, Andrej Mitrovic wrote: On 8/30/13, Namespace rswhi...@googlemail.com wrote: I hate this magic library fix.. Why cannot we use 'scope' for this? I know currently it is an unsafe feature that was also proposed for rejection, but it would look better, feel better, and the compiler could take the dirty work for us. And maybe better optimized. It would also avoid this nasty issue: http://d.puremagic.com/issues/show_bug.cgi?id=10921 Yes. :)
Re: Stride in foreach ranges
On Friday, 30 August 2013 at 14:11:06 UTC, Namespace wrote: On Friday, 30 August 2013 at 06:31:39 UTC, Paul Jurczak wrote: Is there a better way to express a range with stride than this: foreach (i; iota(0, N, 2)) Maybe something similar to F# syntax: foreach (i; 0..2..N) I found this thread suggesting syntax improvement http://forum.dlang.org/thread/bug-411...@http.d.puremagic.com/issues/ but I don't think it produced any results. BTW, DMD produces faster code when for loop is used instead, with GDC it makes no difference. That is strange because the FAQ says here: http://dlang.org/faq.html#foreach [...]let the compiler do the optimization. and Let the compiler pick! Can you prove this on DPaste? It's there at: http://dpaste.dzfl.pl/2cf504db
Re: Regarding emplace, arrays, and helper functions
On 08/30/2013 07:02 AM, Andrej Mitrovic wrote:
However will the compiler align all static arrays so their memory
begins at a proper offset?
The compiler considers only the element type of the static array.
Maybe a more appropriate question is: Is all stack data guaranteed to
be properly aligned, and on all platforms?
I don't know the answer but I don't think it is specified even for C++.
For example:
enum Size = paddedSize!C;
ubyte[1] preBuffer;
ubyte[Size][2] buffer;
Is 'buffer' guaranteed to be aligned so its memory begins at a good
offset?
I don't think so because the elements are ubytes and they can be placed
any odd address. Perhaps it works on the stack but the following
align(1) struct demonstrates that your buffer can be at an odd address:
import std.stdio;
align(1)
struct S
{
ubyte[1] preBuffer;
ubyte[16][2] buffer;
}
void main()
{
writeln(S.preBuffer.offsetof);// prints 0
writeln(S.buffer.offsetof); // prints 1
}
Ali
Re: Stride in foreach ranges
On Friday, 30 August 2013 at 17:19:11 UTC, Paul Jurczak wrote: On Friday, 30 August 2013 at 14:11:06 UTC, Namespace wrote: [..] Can you prove this on DPaste? It's there at: http://dpaste.dzfl.pl/2cf504db I'm not sure what are the compiler switches on DPaste and I don't see an option to change them, so here are my measurements: Windows 7 64-bit Core i5 2500 3.4GHz turbo: DMD 2.063.2 (32-bit): dmd -O -noboundscheck -inline -release 669171001 622ns e28_0 669171001 1244ns e28_1 Xubuntu 13.04 64-bit Core i5 3450S 2.8GHz (3.5GHz turbo): GDC 4.8.1: gdc -m64 -march=native -fno-bounds-check -frename-registers -frelease -O3 669171001 1455ns e28_0 669171001 1458ns e28_1 DMD64 2.063.2: dmd -O -noboundscheck -inline -release 669171001 891ns e28_0 669171001 1572ns e28_1
Re: Stride in foreach ranges
On Friday, 30 August 2013 at 14:18:22 UTC, Dicebot wrote: On Friday, 30 August 2013 at 06:31:39 UTC, Paul Jurczak wrote: BTW, DMD produces faster code when for loop is used instead, with GDC it makes no difference. This pretty much shows that there is nothing wrong in language with current iota approach and it is simply problem of bad dmd code generation. DMD code generation is very good with for loops, not so good with foreach (see my timings in previous post).
Re: Introduction to traits (and __traits)
Am 30.08.2013 21:36, schrieb Joseph Rushton Wakeling:
Hello all,
I find myself wanting to write for the first time one of these
isSomething(T) or hasSomething(T) templates that perform compile-time
checks, so I was hoping people could give me some good general advice on
traits.
The goal here is to be able to confirm (i) type T has certain members
and (ii) they have certain properties. (This is for my graph library,
Dgraph.)
So, to start off with, I thought I'd try starting with,
template isGraph(G)
{
isGraph = __traits(hasMember, G, directed)
isBoolean!(typeof(G.directed));
}
... which I'd assumed would cover the case where G does not have a
member directed. But in fact if I pass it a struct that does not have
the entity .directed defined therein, it will return an error: no
property 'directed' for type ...
So, can someone give me a good idea of how to go about writing such a
compile-time template that checks (i) for the existence of certain
methods/functions/members and (ii) confirms their characteristics, such
as their return values or arguments?
Thanks best wishes,
-- Joe
You need to put it into a static if, otherwise the compiler will
continue semantic checks on the second part of the expression. E.g.
template isGraph(G)
{
static if(__traits(hasMember, G, directed))
enum bool isGraph = isBoolean!(typeof(G.directed));
else
enum bool isGraph = false;
}
Introduction to traits (and __traits)
Hello all,
I find myself wanting to write for the first time one of these isSomething(T) or
hasSomething(T) templates that perform compile-time checks, so I was hoping
people could give me some good general advice on traits.
The goal here is to be able to confirm (i) type T has certain members and (ii)
they have certain properties. (This is for my graph library, Dgraph.)
So, to start off with, I thought I'd try starting with,
template isGraph(G)
{
isGraph = __traits(hasMember, G, directed)
isBoolean!(typeof(G.directed));
}
... which I'd assumed would cover the case where G does not have a member
directed. But in fact if I pass it a struct that does not have the entity
.directed defined therein, it will return an error: no property 'directed' for
type ...
So, can someone give me a good idea of how to go about writing such a
compile-time template that checks (i) for the existence of certain
methods/functions/members and (ii) confirms their characteristics, such as their
return values or arguments?
Thanks best wishes,
-- Joe
Re: Introduction to traits (and __traits)
On 30/08/13 21:40, Benjamin Thaut wrote:
You need to put it into a static if, otherwise the compiler will continue
semantic checks on the second part of the expression. E.g.
template isGraph(G)
{
static if(__traits(hasMember, G, directed))
enum bool isGraph = isBoolean!(typeof(G.directed));
else
enum bool isGraph = false;
}
Ahh, right, thanks. :-)
Is there a recommended way for handling the case where there are many such
members -- say about 10 or more? The static if's could become very highly
nested with this approach. I suppose I could go through like this:
static if(!__traits(hasMember, G, one))
enum bool isGraph = false;
else static if(!__traits(hasMember, G, two))
enum bool isGraph = false;
else static if ...
...
else
{
// Now I know all the members exist and I can
// start checking out their properties ...
}
Re: PyD status and tutorials
Hello, Not working here on a Debian sid : gdc -fproperty -c -fversion=Python_2_4_Or_Later -fversion=Python_2_5_Or_Later -fversion=Python_2_6_Or_Later -fversion=Python_2_7_Or_Later -fversion=Python_3_0_Or_Later -fversion=Python_3_1_Or_Later -fversion=Python_3_2_Or_Later -fversion=Python_3_3_Or_Later -fversion=Python_Unicode_UCS4 -fdebug -I /usr/local/lib/python3.3/dist-packages/celerid/infrastructure -o build/temp.linux-x86_64-3.3/infra/temp.o hello.d /usr/local/lib/python3.3/dist-packages/celerid/infrastructure/pyd/class_wrap.d /usr/local/lib/python3.3/dist-packages/celerid/infrastructure/pyd/ctor_wrap.d ... [lot of text here, won't copy-paste everything, should I] ... def: hello wrap_struct: 'RangeWrapper' class.def: __iter__ class.def: next wrapped_struct_init, S is 'struct pyd.make_object.RangeWrapper' library_dirs: [] runtime_library_dirs: [] libraries: ['python3.3m'] gdc -fdebug -o build/lib.linux-x86_64-3.3/hello build/temp.linux-x86_64-3.3/infra/temp.o -lpython3.3m /usr/bin/ld: cannot find -lpython3.3m collect2: error: ld returned 1 exit status error: command 'gdc' failed with exit status 1 Any clue ? Thanks
Re: PyD status and tutorials
Ah, forgot to say : I executed python3.3 setup.py pydexe --compiler=gdc Any other way won't work. tried hacking dcompiler.py in the python local packages, no luck. Libraries won't be taken into account. May I read something wrong..
Re: Introduction to traits (and __traits)
On 30/08/13 23:06, Ali Çehreli wrote:
How about allSatisfy:
http://dlang.org/phobos/std_typetuple.html#.allSatisfy
I'll have a look at that, thanks :-)
Here's what I came up with, for now. It should probably be extended with
further tests on the characteristics of the various member functions but it
seems to be sufficient for now:
template isGraph(G)
{
static if (!__traits(hasMember, G, directed) ||
!__traits(hasMember, G, edge) ||
!__traits(hasMember, G, edgeCount) ||
!__traits(hasMember, G, vertexCount) ||
!__traits(hasMember, G, isEdge) ||
!__traits(hasMember, G, edgeID) ||
!__traits(hasMember, G, addEdge) ||
!__traits(hasMember, G, degreeIn) ||
!__traits(hasMember, G, degreeOut) ||
!__traits(hasMember, G, incidentEdgesIn) ||
!__traits(hasMember, G, incidentEdgesOut) ||
!__traits(hasMember, G, neighboursIn) ||
!__traits(hasMember, G, neighboursOut))
{
enum bool isGraph = false;
}
else static if (!isBoolean!(typeof(G.directed)))
{
enum bool isGraph = false;
}
else static if (G.directed (__traits(hasMember, G, degree) ||
__traits(hasMember, G, incidentEdges) ||
__traits(hasMember, G, neighbours)))
{
enum bool isGraph = false;
}
else static if (!G.directed (!__traits(hasMember, G, degree) ||
!__traits(hasMember, G, incidentEdges) ||
!__traits(hasMember, G, neighbours)))
{
enum bool isGraph = false;
}
else
{
enum bool isGraph = true;
}
}
Re: Introduction to traits (and __traits)
On 08/30/2013 01:57 PM, Joseph Rushton Wakeling wrote:
On 30/08/13 21:40, Benjamin Thaut wrote:
You need to put it into a static if, otherwise the compiler will continue
semantic checks on the second part of the expression. E.g.
template isGraph(G)
{
static if(__traits(hasMember, G, directed))
enum bool isGraph = isBoolean!(typeof(G.directed));
else
enum bool isGraph = false;
}
Ahh, right, thanks. :-)
Is there a recommended way for handling the case where there are many
such members -- say about 10 or more? The static if's could become very
highly nested with this approach. I suppose I could go through like this:
static if(!__traits(hasMember, G, one))
enum bool isGraph = false;
else static if(!__traits(hasMember, G, two))
enum bool isGraph = false;
else static if ...
...
else
{
// Now I know all the members exist and I can
// start checking out their properties ...
}
How about allSatisfy:
http://dlang.org/phobos/std_typetuple.html#.allSatisfy
Ali
Re: Introduction to traits (and __traits)
On Fri, Aug 30, 2013 at 11:51:37PM +0200, bearophile wrote:
Joseph Rushton Wakeling:
static if (!__traits(hasMember, G, directed) ||
!__traits(hasMember, G, edge) ||
!__traits(hasMember, G, edgeCount) ||
!__traits(hasMember, G, vertexCount) ||
!__traits(hasMember, G, isEdge) ||
!__traits(hasMember, G, edgeID) ||
!__traits(hasMember, G, addEdge) ||
!__traits(hasMember, G, degreeIn) ||
!__traits(hasMember, G, degreeOut) ||
!__traits(hasMember, G, incidentEdgesIn) ||
!__traits(hasMember, G, incidentEdgesOut) ||
!__traits(hasMember, G, neighboursIn) ||
!__traits(hasMember, G, neighboursOut))
Perhaps can shorten that code writing a hasMembers helper (and I
suggest to keep those names sorted):
[...]
Here's a first stab at a possible implementation:
/* Warning: untested code */
import std.typetuple : allSatisfy;
template isString(T) {
// There may already be something in Phobos that does
// this, but I'm too lazy to look.
enum isString = is(T == string);
}
template hasMembers(alias T, Members...)
if (allSatisfy!isString(Members))
{
// Template recursion + exprTuple slicing FTW :)
enum hasMembers = __traits(hasMember, T, Members[0])
hasMembers!(T, Members[1..$]);
}
void myFunc(G)(G graph)
{
static if (hasMembers!(G, directed, edge, /* ... */))
{
...
}
}
T
--
Computers shouldn't beep through the keyhole.
Re: Introduction to traits (and __traits)
Joseph Rushton Wakeling:
static if (!__traits(hasMember, G, directed) ||
!__traits(hasMember, G, edge) ||
!__traits(hasMember, G, edgeCount) ||
!__traits(hasMember, G, vertexCount) ||
!__traits(hasMember, G, isEdge) ||
!__traits(hasMember, G, edgeID) ||
!__traits(hasMember, G, addEdge) ||
!__traits(hasMember, G, degreeIn) ||
!__traits(hasMember, G, degreeOut) ||
!__traits(hasMember, G, incidentEdgesIn) ||
!__traits(hasMember, G, incidentEdgesOut) ||
!__traits(hasMember, G, neighboursIn) ||
!__traits(hasMember, G, neighboursOut))
Perhaps can shorten that code writing a hasMembers helper (and I
suggest to keep those names sorted):
static if (hasMembers!(G, addEdge
degreeIn
...
vertexCount.split) {
Bye,
bearophile
Re: Introduction to traits (and __traits)
On 30/08/13 23:51, bearophile wrote: Perhaps can shorten that code writing a hasMembers helper (and I suggest to keep those names sorted) Nice thought, I might look into that at some point. :-)
Re: A little of coordination for Rosettacode
I have added a D entry for the Go Fish game: http://rosettacode.org/wiki/Go_Fish#D I don't know the Go Fish game, so I am not sure this code is correct. Is some of you able and willing to test its play a bit? (This D entry is very Python-style because it's a translation of the Python entry, so it's not very strongly typed. Generally in D I prefer stronger typing, but in this case I think it's acceptable). Bye, bearophile
Re: A little of coordination for Rosettacode
the entry : http://rosettacode.org/wiki/File_IO is wrong because as stated by the asignment : In this task, the job is to create a file called output.txt, and place in it the contents of the file input.txt, *via an intermediate variable.*** * * there is no intermediate variable; I don't know if this is the right place to post but you seem to do a lot of work for rosetta... 2013/8/31 bearophile bearophileh...@lycos.com I have added a D entry for the Go Fish game: http://rosettacode.org/wiki/**Go_Fish#Dhttp://rosettacode.org/wiki/Go_Fish#D I don't know the Go Fish game, so I am not sure this code is correct. Is some of you able and willing to test its play a bit? (This D entry is very Python-style because it's a translation of the Python entry, so it's not very strongly typed. Generally in D I prefer stronger typing, but in this case I think it's acceptable). Bye, bearophile
Re: A little of coordination for Rosettacode
On Saturday, 31 August 2013 at 01:42:43 UTC, bearophile wrote: I have added a D entry for the Go Fish game: hmm there's too much text output, it makes following the game hard, and seeing what the computer drew means you can cheat! But I think it plays correctly, I was able to finish a game. -- Speaking of card games, did you know Windows comes with a cards.dll that can draw a set of playing cards? It is used for built in games like Solitare. And you can use it too! Here's an example of how: http://arsdnet.net/dcode/wincards.d See the main function at the bottom of the file. The main() depends on (the newer version of) my simpledisplay.d and color.d (also shows how to use some of the input event improvements I've made over the last couple weeks!) https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff The sample program puts two cards on the screen and lets you drag them around with the mouse. Only works on MS Windows.
Re: A little of coordination for Rosettacode
On 31-8-2013 4:08, maarten van damme wrote: the entry : http://rosettacode.org/wiki/File_IO is wrong because as stated by the asignment : In this task, the job is to create a file called output.txt, and place in it the contents of the file input.txt, /via an intermediate variable./// / / there is no intermediate variable; I don't know if this is the right place to post but you seem to do a lot of work for rosetta... It's an old task (from 2007). The task description was changed after the D entries were made. http://rosettacode.org/mw/index.php?title=File_IOdiff=25166oldid=21823 So it needs to be updated. Perhaps you will do the honors? :)
how to print the tested-condition in myAsssert -- stringification needed
I'm using the myAssert() suggested by others in the D forum, with
a few tweaks:
void myAssert(int line = __LINE__, string file = __FILE__,
Args...)(lazy bool condition, lazy Args args) {
string string_version_of_condition = //? how?
if (!condition)
{
writefln(Assertion (%s) failed @ %s:%d in test '%s',
string_version_of_condition, file, line, currentTestName);
foreach(a; args) {
write( assert-extra: );
writeln(a);
}
exit(1);
}
}
}
This is great, but I would also like to print out the stringified
version of the condition, so that the assert shows me the text of
the failed test-condition.
e.g.
myAssert(1 == 0);
// should result in:
Assertion (1 == 0) failed @ test.d:34 in test 'bool test'
How to I initialize string_version_of_condition? In C/C++, I'd
use a macro and token pasting.
