[Issue 9580] std.variant.Algebraic with Tuple format problem
http://d.puremagic.com/issues/show_bug.cgi?id=9580
Andrei Alexandrescu and...@erdani.com changed:
What|Removed |Added
CC||and...@erdani.com
--- Comment #1 from Andrei Alexandrescu and...@erdani.com 2013-02-23 23:55:44
PST ---
I'm on the road now but a quick test suggests that simply providing an empty
definition for This fixes the problem:
struct This {}
Can someone give it a shot?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8441] mixin containing template functions causes compiler errors
http://d.puremagic.com/issues/show_bug.cgi?id=8441 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #8 from Kenji Hara k.hara...@gmail.com 2013-02-24 00:08:50 PST --- I don't test std.signal2 module, but the two test cases work with my patch. https://github.com/D-Programming-Language/dmd/pull/1660 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9258] opAssign with base class triggers identity assignment operator overload error
http://d.puremagic.com/issues/show_bug.cgi?id=9258 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9566] Regression (2.062): Cannot use struct .init when it contains a static array initialized from a single element.
http://d.puremagic.com/issues/show_bug.cgi?id=9566 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #3 from Kenji Hara k.hara...@gmail.com 2013-02-24 02:25:00 PST --- https://github.com/D-Programming-Language/dmd/pull/1688 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9343] Problem installing dmd-2.061-0.fedora.x86_64.rpm on Fedora 18
http://d.puremagic.com/issues/show_bug.cgi?id=9343 Jordi Sayol g.sa...@yahoo.es changed: What|Removed |Added CC||g.sa...@yahoo.es --- Comment #17 from Jordi Sayol g.sa...@yahoo.es 2013-02-24 03:10:04 PST --- Bug fixed on the rpm building script. Here you can download fixed rpm packages: http://d-packages.googlecode.com/files/dmd-2.062-1.fedora.i386.rpm http://d-packages.googlecode.com/files/dmd-2.062-1.fedora.x86_64.rpm I didn't know about this bug, so please, next time you can inform the packager too for a faster solution. This information is present on every rpm package, and is for situations like this: $ rpm -qpi dmd-X.XXX-X.fedora.x86_64.rpm -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9343] Problem installing dmd-2.061-0.fedora.x86_64.rpm on Fedora 18
http://d.puremagic.com/issues/show_bug.cgi?id=9343 Jordi Sayol g.sa...@yahoo.es changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] New: std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582
Summary: std.algorithm.map!(T) cause CT error for fixed size
arrays
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: marm...@gmail.com
--- Comment #0 from Marcin Mstowski marm...@gmail.com 2013-02-24 06:43:45 PST
---
void main() {
float[5] smt = [0, 1, 2, 4, 100];
auto ms = map!a*a(smt);
}
DMD 2.062 gives:
dmd test.d
test.d(5): Error: template std.algorithm.map!(a*a).map does not match any
function template declaration. Candidates are:
..\..\src\phobos\std\algorithm.d(379):
std.algorithm.map!(a*a).map(Range)(Range r) if
(isInputRange!(Unqual!(Range)))
test.d(5): Error: template std.algorithm.map!(a*a).map(Range)(Range r) if
(isInputRange!(Unqual!(Range))) cannot deduce template function from argument
types!()(float[5u])
Dynamic arrays for map!T and reduce!T with static arrays (not tested for others
functions) compile without problem.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9581] Regression (2.053): Exception takes too much time to show up
http://d.puremagic.com/issues/show_bug.cgi?id=9581 --- Comment #9 from Steven Schveighoffer schvei...@yahoo.com 2013-02-24 06:52:00 PST --- (In reply to comment #8) Exceptions in general are overly slow. Yeah, but not *4 seconds* slow, that is unacceptable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc 2013-02-24 07:31:48 PST ---
(In reply to comment #0)
void main() {
float[5] smt = [0, 1, 2, 4, 100];
auto ms = map!a*a(smt);
}
Only certain higher order functions of Phobos work with fixed-sized arrays:
import std.algorithm: reduce;
void main() {
float[5] smt = [0, 1, 2, 4, 100];
assert(reduce!a+b(smt) == 107); // OK.
}
So probably this bug report should be closed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #2 from Peter Alexander peter.alexander...@gmail.com 2013-02-24 08:08:11 PST --- This is by design. map expects an input range. Static arrays are not input ranges. You have to take a slice. auto ms = map!a*a(smt[]); // note additional [] reduce only requires an iterable, which includes static arrays. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #3 from monarchdo...@gmail.com 2013-02-24 08:11:52 PST --- (In reply to comment #2) This is by design. map expects an input range. Static arrays are not input ranges. You have to take a slice. auto ms = map!a*a(smt[]); // note additional [] reduce only requires an iterable, which includes static arrays. ...and this is good example of why accepting an iterable as a function argument, as opposed to a range, is usually a bad idea. As for reduce accepting iterable, Andrei asked me to remove it in one of my open requests, so don't expect it keep working for too long. https://github.com/D-Programming-Language/phobos/pull/861#discussion_r2024457 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582 --- Comment #4 from Peter Alexander peter.alexander...@gmail.com 2013-02-24 08:16:44 PST --- (In reply to comment #3) ...and this is good example of why accepting an iterable as a function argument, as opposed to a range, is usually a bad idea. As for reduce accepting iterable, Andrei asked me to remove it in one of my open requests, so don't expect it keep working for too long. https://github.com/D-Programming-Language/phobos/pull/861#discussion_r2024457 std.array.array also accepts iterables. I think array and reduce are the only two. Removing these is going to break a lot of code though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582 --- Comment #5 from monarchdo...@gmail.com 2013-02-24 08:21:49 PST --- (In reply to comment #4) (In reply to comment #3) ...and this is good example of why accepting an iterable as a function argument, as opposed to a range, is usually a bad idea. As for reduce accepting iterable, Andrei asked me to remove it in one of my open requests, so don't expect it keep working for too long. https://github.com/D-Programming-Language/phobos/pull/861#discussion_r2024457 std.array.array also accepts iterables. I think array and reduce are the only two. Removing these is going to break a lot of code though. For array, probably. For reduce, probably much less. I think ideally, we should accept isNonStaticArrayItterable: The idea of isIterable is to accept stuff that is either a range, or has opApply. Static arrays, while being iterable, shouldn't be passed around by value to functions. I think there'd be gains in the long run to such a scheme. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582 --- Comment #6 from bearophile_h...@eml.cc 2013-02-24 08:52:34 PST --- (In reply to comment #3) As for reduce accepting iterable, Andrei asked me to remove it in one of my open requests, so don't expect it keep working for too long. I am strongly against this breaking change. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8331] Problem with sort!(SwapStrategy.stable)
http://d.puremagic.com/issues/show_bug.cgi?id=8331 Xinok xi...@live.com changed: What|Removed |Added CC||xi...@live.com --- Comment #2 from Xinok xi...@live.com 2013-02-24 08:57:54 PST --- Previously, the stable sort in Phobos was broken which may be why this code failed. It has since been fixed, so if that was indeed the problem, we can probably close this bug report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5028] Problem with named mixins in base class and derived class
http://d.puremagic.com/issues/show_bug.cgi?id=5028
Damian damian...@hotmail.co.uk changed:
What|Removed |Added
CC||damian...@hotmail.co.uk
--- Comment #3 from Damian damian...@hotmail.co.uk 2013-02-24 09:28:47 PST ---
I ran into this bug using std.signals and is currently a blocker for me,
making std.signals useless, so I must use another mechanism. This is a example:
import std.signals;
class ClassA
{
public mixin Signal!(int) addNumber1;
}
class ClassB : ClassA
{
public mixin Signal!(int) addNumber2;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9583] New: std.getopt.getopt does not consume options terminator -- from args list, as docs claim
http://d.puremagic.com/issues/show_bug.cgi?id=9583
Summary: std.getopt.getopt does not consume options terminator
-- from args list, as docs claim
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx
--- Comment #0 from hst...@quickfur.ath.cx 2013-02-24 10:43:56 PST ---
Code:
import std.getopt;
import std.stdio;
void main(string[] args) {
int opt;
writeln(args);
getopt(args, opt, opt);
writeln(args);
}
Results:
$ ./test --opt=123 -- --a --b --c
[./test, --opt=123, --, --a, --b, --c]
[./test, --, --a, --b, --c]
$
Contrary to what the docs claim, the options terminator -- is not consumed by
getopt.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5028] Problem with named mixins in base class and derived class
http://d.puremagic.com/issues/show_bug.cgi?id=5028
--- Comment #4 from Denis Shelomovskij verylonglogin@gmail.com 2013-02-24
23:11:51 MSK ---
(In reply to comment #3)
I ran into this bug using std.signals and is currently a blocker for me,
making std.signals useless, so I must use another mechanism. This is a
example:
import std.signals;
class ClassA
{
public mixin Signal!(int) addNumber1;
}
class ClassB : ClassA
{
public mixin Signal!(int) addNumber2;
}
A workaround:
Add dummy signal `private mixin Signal!(int) __dummy;` to `ClassA`.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9583] std.getopt.getopt does not consume options terminator -- from args list, as docs claim
http://d.puremagic.com/issues/show_bug.cgi?id=9583 --- Comment #1 from hst...@quickfur.ath.cx 2013-02-24 12:16:42 PST --- https://github.com/D-Programming-Language/phobos/pull/1159 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8034] Template mixins creates ambiguous virtual function
http://d.puremagic.com/issues/show_bug.cgi?id=8034 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||WORKSFORME --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-24 13:22:04 PST --- Fixed since 2.060. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7465] Duplicate error message for bad template mixin
http://d.puremagic.com/issues/show_bug.cgi?id=7465 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-24 13:23:54 PST --- Getting worse, it's now 3 error messages in 2.062. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5028] Problem with named mixins in base class and derived class
http://d.puremagic.com/issues/show_bug.cgi?id=5028
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-24
13:29:19 PST ---
(In reply to comment #2)
The issue is that this doesn't compile:
---
mixin template T() { final void f() { } }
class A { mixin T ta; }
class B : A { mixin T tb; }
---
This would be an enhancement request though, the spec doesn't say the symbols
are only visible by using 'ta' and 'tb'.
The issue name here is a misnomer, it's unrelated to base/derived classes.
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=8785
http://d.puremagic.com/issues/show_bug.cgi?id=8033
So this would really be an enhancement request to make symbols in mixin
templates unavailable in the current scope when a mixin identifier is used:
mixin template T() { final void f() { } }
class A { mixin T ta; }
class B : A { mixin T tb; }
With the enhancement only A.ta.f() and B.tb.f() would be visible, A.f() and
B.f() would be invisible.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9583] std.getopt.getopt does not consume options terminator -- from args list, as docs claim
http://d.puremagic.com/issues/show_bug.cgi?id=9583 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Keywords||pull CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-24 13:35:00 PST --- H. S. Teoh's pull: https://github.com/D-Programming-Language/phobos/pull/1159 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9583] std.getopt.getopt does not consume options terminator -- from args list, as docs claim
http://d.puremagic.com/issues/show_bug.cgi?id=9583 --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-24 13:35:25 PST --- (In reply to comment #2) H. S. Teoh's pull: https://github.com/D-Programming-Language/phobos/pull/1159 Woops I didn't see you already pasted the link. The 'pull' keyword was missing though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582 --- Comment #7 from bearophile_h...@eml.cc 2013-02-24 13:49:05 PST --- (In reply to comment #6) I am strongly against this breaking change. Sorry, that came out too much strong... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8331] Problem with sort!(SwapStrategy.stable)
http://d.puremagic.com/issues/show_bug.cgi?id=8331 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from bearophile_h...@eml.cc 2013-02-24 13:52:56 PST --- (In reply to comment #2) Previously, the stable sort in Phobos was broken which may be why this code failed. It has since been fixed, so if that was indeed the problem, we can probably close this bug report. Right, thank you. Closed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8331] Problem with sort!(SwapStrategy.stable)
http://d.puremagic.com/issues/show_bug.cgi?id=8331 bearophile_h...@eml.cc changed: What|Removed |Added Resolution|FIXED |WORKSFORME -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582 --- Comment #8 from monarchdo...@gmail.com 2013-02-24 13:59:12 PST --- (In reply to comment #7) (In reply to comment #6) I am strongly against this breaking change. Sorry, that came out too much strong... Don't worry about it, I didn't even perceive anything that could be offensive. Can you elaborate on the why though? Is it just because it would be breaking change, or do you have a use case that warrants its being in there in the first place (more so than any algorithm I mean)? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9536] IFTI fails when calling a static member from const member
http://d.puremagic.com/issues/show_bug.cgi?id=9536 --- Comment #2 from github-bugzi...@puremagic.com 2013-02-24 14:07:38 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ce87b314b5e0d3ae98bd22c765efa2c08f837514 fix Issue 9536 - IFTI fails when calling a static member from const member https://github.com/D-Programming-Language/dmd/commit/d8eeecf4cba19d9bb22fb146b9ba7f5ff41453e9 Merge pull request #1683 from 9rnsr/fix9536 [REG2.059] Issue 9536 - IFTI fails when calling a static member from const member -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9536] IFTI fails when calling a static member from const member
http://d.puremagic.com/issues/show_bug.cgi?id=9536 --- Comment #3 from github-bugzi...@puremagic.com 2013-02-24 14:11:32 PST --- Commit pushed to 2.062 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c39a398fa95a46044dd7a8f2aac8f03437de7d8d Merge pull request #1683 from 9rnsr/fix9536 [REG2.059] Issue 9536 - IFTI fails when calling a static member from const member -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9566] Regression (2.062): Cannot use struct .init when it contains a static array initialized from a single element.
http://d.puremagic.com/issues/show_bug.cgi?id=9566 --- Comment #4 from github-bugzi...@puremagic.com 2013-02-24 14:19:30 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ac3de50bcff047b86ff8fe8778f00e8f4845315c fix Issue 9566 - Cannot use struct .init when it contains static array initialized from a single element. https://github.com/D-Programming-Language/dmd/commit/f5eb6d5f9684ff6276cdbc52919b5b877d36d72d Merge pull request #1688 from 9rnsr/fix9566 [REG 2.062] Issue 9566 - Cannot use struct .init when it contains static array initialized from a single element. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9566] Regression (2.062): Cannot use struct .init when it contains a static array initialized from a single element.
http://d.puremagic.com/issues/show_bug.cgi?id=9566 --- Comment #5 from github-bugzi...@puremagic.com 2013-02-24 14:21:22 PST --- Commit pushed to 2.062 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e8521cb9e23119a50a6d97af0f5d9e6e5e16f8bf Merge pull request #1688 from 9rnsr/fix9566 [REG 2.062] Issue 9566 - Cannot use struct .init when it contains static array initialized from a single element. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9576] Symbol Undefined linker error on using `std.random.MinstdRand`
http://d.puremagic.com/issues/show_bug.cgi?id=9576 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2013-02-24 14:32:58 PST --- What version of dmd did this work in? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9581] Regression (2.053): Exception takes too much time to show up
http://d.puremagic.com/issues/show_bug.cgi?id=9581 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #10 from Walter Bright bugzi...@digitalmars.com 2013-02-24 14:34:52 PST --- This may have something to do with an earlier complaint that dbghelp.dll was searching one's entire hard disk looking for a source file. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582
--- Comment #9 from bearophile_h...@eml.cc 2013-02-24 14:40:31 PST ---
(In reply to comment #8)
Can you elaborate on the why though? Is it just because it would be
breaking
change, or do you have a use case that warrants its being in there in the
first place (more so than any algorithm I mean)?
I have a good amount of functional-style D2 code with hundreds of usages of
reduce. And in D I use fixed-sized arrays all the time to reduce heap activity,
so probably this change will require me some fixes in my code, to add the [].
I don't like this change in principle, because I like fixed-size arrays, I use
them all the time, and I think they should be more first class in Phobos. I'd
like more Phobos functions to work with fixed size arrays, not less functions.
Also, reduce() doesn't return part of the input, it creates a new output, so it
the code that uses the result of reduce() doesn't need to care what reduce()
was fed with. The same is true for array(). I think reduce() and array() should
also work on opApply, for maximum flexibility.
The higher order functions of my D1 nonstandard library accepted both kinds of
arrays, and even associative arrays as inputs. I prefer more flexibility. And I
think that forcing everything inside the mindframe of Ranges is a not a good
idea. Iteration life is more complex:
http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/
In past I have asked one small changes in Phobos that was closed down because
despite it being handy and useful, it was a small breaking change. Forbidding
fixed size arrays as reduce inputs _reduces_ flexibility, and it's a larger
breaking change.
In the end I am probably able to add the missing [] to my D2 code in a matter
of one or two hours (or less) so for me this change doesn't require me a lot of
work to fix. So I leave the decision to you.
---
Static arrays, while being iterable, shouldn't be passed around by
value to functions. I think there'd be gains in the long run to such a scheme.
Let's say I have this fixed-sized array:
int[3] items = [1, 2, 3];
and I want to compute its sum:
reduce!q{a + b}(items)
In this case ideally I'd like the D compiler to replace that call to reduce
with the same ASM as
items[0] + items[1] + items[2]
This means the compiler has some compile-time information (the array length)
that in theory (and in practice too if the code is well written and you are
using a GCC back-end that is able to unroll small loops) is usable to produce
full optimized code.
If I have to write:
reduce!q{a + b}(items[])
Then we have lost something, the reduce() can't know at compile-time the length
of the array, so performing loop unrolling becomes harder (the JavaVM is able
to partially unroll the loop in this case too, but LLVM was not able to do it
since the latest version, and even now it's not perfect).
Throwing away some compile-time information seems a bad idea to me.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9581] Regression (2.053): Exception takes too much time to show up
http://d.puremagic.com/issues/show_bug.cgi?id=9581 --- Comment #11 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-24 14:42:31 PST --- (In reply to comment #10) This may have something to do with an earlier complaint that dbghelp.dll was searching one's entire hard disk looking for a source file. That specific bug was fixed though (and I can confirm it was fixed). But there's still this delay of several seconds before the message shows up. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9581] Regression (2.053): Exception takes too much time to show up
http://d.puremagic.com/issues/show_bug.cgi?id=9581 --- Comment #12 from Jonathan M Davis jmdavisp...@gmx.com 2013-02-24 14:49:01 PST --- Yeah, but not *4 seconds* slow, that is unacceptable. Of course, though this involves a lot more than simply throwing and catching an exception, which changes the equation a bit (though 4 seconds is still too slow). By the way, I just tried this on Linux for comparison, and it took about 8ms on my machine. So, this is clearly a Windows-only issue (though I just used the time command to time it rather than writing a program; Does Windows not have anything similar? Probably not, given how limited its command line capabilities are). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9581] Regression (2.053): Exception takes too much time to show up
http://d.puremagic.com/issues/show_bug.cgi?id=9581 --- Comment #13 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-24 14:55:05 PST --- (In reply to comment #12) By the way, I just tried this on Linux for comparison, and it took about 8ms on my machine. I can confirm that, it only takes 3ms in Linux Mint in a VBox. It's a Windows issue. (In reply to comment #12) Does Windows not have anything similar? It has `timeit` available from http://www.microsoft.com/en-us/download/details.aspx?id=17657 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582
--- Comment #10 from monarchdo...@gmail.com 2013-02-24 15:41:59 PST ---
(In reply to comment #9)
In the end I am probably able to add the missing [] to my D2 code in a matter
of one or two hours (or less) so for me this change doesn't require me a lot
of
work to fix. So I leave the decision to you.
I'm not that passionate on the issue. I think treating static arrays as ranges
in the first place wasn't the best idea. I mean, if your code didn't compile in
the first place, you would have probably called it with arr[] and not have
though about it much more.
I also agree that working on things with opApply adds useability, such as for
std.array.array. How ever, I don't think it warrants passing a static array by
value, and creating a template instance per array size.
Static arrays, while being iterable, shouldn't be passed around by
value to functions. I think there'd be gains in the long run to such a
scheme.
Let's say I have this fixed-sized array:
int[3] items = [1, 2, 3];
and I want to compute its sum:
reduce!q{a + b}(items)
In this case ideally I'd like the D compiler to replace that call to reduce
with the same ASM as
items[0] + items[1] + items[2]
This means the compiler has some compile-time information (the array length)
that in theory (and in practice too if the code is well written and you are
using a GCC back-end that is able to unroll small loops) is usable to produce
full optimized code.
If I have to write:
reduce!q{a + b}(items[])
Then we have lost something, the reduce() can't know at compile-time the
length
of the array, so performing loop unrolling becomes harder (the JavaVM is able
to partially unroll the loop in this case too, but LLVM was not able to do it
since the latest version, and even now it's not perfect).
Throwing away some compile-time information seems a bad idea to me.
But the way I see it, your argument is that loop unrolling justifies copying an
entire array. I'm not really sure it is. Can you honestly tell me that when you
wrote reduce(myArray), you realized you were passing it by value?
Furthermore, is the performance gain *also* worth the template bloat, since you
are instantiating 1 reduce algorithm per array *size*.
C++ could do this, but it doesn't. Ever. And C++ is dead serious about
squeezing every last ounce of performance it can, algorithm wise.
The ideal solution would be one akin to cycle: A specialized overload that
takes static arrays by reference. You get your cheap pass by ref, but also keep
your compile time info.
But still, that is a *very* specific use case, with a code deployment cost, and
shouldn't be used many other things.
So my conclusion is that: Yes, for useability reason, taking an iterable is
good. However, for the sake of arguments accepted, I don't think a static array
should be considered an iterable, and the caller should be expected to slice
it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9584] New: Exceptions in D are ludicrously slow (far worse than Java)
http://d.puremagic.com/issues/show_bug.cgi?id=9584
Summary: Exceptions in D are ludicrously slow (far worse than
Java)
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2013-02-24 15:46:57
PST ---
Take this D program
--
import std.conv;
import std.datetime;
import std.stdio;
void main()
{
auto sw = StopWatch(AutoStart.yes);
try
throw new Exception(blah);
catch(Exception e)
{
auto diff = to!Duration(sw.peek());
writeln(diff.total!hnsecs());
writeln(diff);
}
}
--
and this Java program
--
class j
{
public static final void main(String[] args)
{
long before = System.nanoTime();
try
{
throw new Exception(blah);
}
catch(Exception e)
{
long diff = System.nanoTime() - before;
long totalHNSecs = diff / 100;
long msecs = diff / 100;
diff -= msecs * 100;
long usecs = diff / 1000;
diff -= usecs * 1000;
long hnsecs = diff / 100;
System.out.println(totalHNSecs);
System.out.printf(%sms %sus %shnsecs\n, msecs, usecs, hnsecs);
}
}
}
--
They are roughly equivalent, but their performance is drastically different
(and Java wins by a _long_ shot). These are typical outputs for the D version
13962
1 ms, 396 μs, and 2 hnsecs
13658
1 ms, 365 μs, and 8 hnsecs
13745
1 ms, 374 μs, and 5 hnsecs
whereas tese are typical outputs for the Java version
126
0ms 12us 6hnsecs
126
0ms 12us 6hnsecs
140
0ms 14us 0hnsecs
It varies a bit from execution to execution (particularly for D), but in
general, I'm seeing that D is taking 90x - 110x longer than Java is. Oddly,
once in a blue moon, D seems to take more like 20x longer, but even that's a
huge difference (and not in D's favor). In general, Java shouldn't be beating D
for performance, since D is a systems language, and a magnitute of 100x is
pathetic.
Granted, code should not be constantly throwing and catching exeptions, but
this sort of bad performance can make it so that exceptions have far more of a
negative impact then they should. The place that this is particularly negative
is in unit tests. Good unit tests will test that functions act appropriately
when given bad input, which generally means that they throw exceptions, and the
tests catch them, and right now, if you do much of that, unit tests start
taking a very long time to execute - unacceptably long. This makes it so that
code must be tested less in order for the tests to take a reasonable amount of
time, which will lead to worse code quality.
So, I think that it's clear that we need to take steps to improve the
performance of throwing and catching exceptions. As I understand it, the
stacktrace is currently put into string format when the exception is
constructed, which is unnecessary overhead if the stack trace never gets
printed, so that's one improvement that could be made. But I have no idea how
the internals of any of this currently work, so I don't know what other
improvements could be made. Regardless, we need to take steps to significantly
improve the situation.
Note that these tests were done on Linux. I don't know how the times compare on
Windows, though I expect that the situation is similar there.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9581] Regression (2.053): Exception takes too much time to show up
http://d.puremagic.com/issues/show_bug.cgi?id=9581 --- Comment #14 from Jonathan M Davis jmdavisp...@gmx.com 2013-02-24 15:49:48 PST --- I couldn't find a bug report dealing with the general bad performance of exceptions, so I just created one: bug# 9584 So, that's related to this, but something here is making it far worse in this particular situation. In general, they're taking milliseconds when they should be taking microseconds, whereas here they're taking seconds. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9582] std.algorithm.map!(T) cause CT error for fixed size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9582
--- Comment #11 from bearophile_h...@eml.cc 2013-02-24 16:11:10 PST ---
(In reply to comment #10)
But the way I see it, your argument is that loop unrolling justifies copying
an
entire array.
If your array is a ubyte[6] then I think copying it is OK, otherwise it's
better to take the fixed size array by reference.
Furthermore, is the performance gain *also* worth the template bloat,
since you are instantiating 1 reduce algorithm per array *size*.
The compile-time knowledge of the array length gives a performance advantage
for small arrays only, that's why I have used a items int[3] in my example. A
way to keep the template bloat low is to introduce a limit of the length with a
template constraint:
import std.stdio;
void foo(T, size_t N)(ref T[N] items) if (N 10) {
writeln(foo 1);
}
void foo(T)(T[] items) {
writeln(foo 2);
}
void main() {
int[3] a1;
int[20] a2;
int[] a3;
foo(a1);
foo(a2);
foo(a3);
}
Prints:
foo 1
foo 2
foo 2
(There is another way to solve this problem, but I think it requires a small
improvement of D language (it's an idea to help reduce the template bloat in
some situations, like with fixed size arrays), but while you design reduce()
you can't assume such change, that currently is not even written in a bugzilla
enhancement request entry.)
The ideal solution would be one akin to cycle: A specialized overload that
takes static arrays by reference. You get your cheap pass by ref, but also
keep
your compile time info.
But still, that is a *very* specific use case, with a code deployment cost,
and
shouldn't be used many other things.
OK.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5359] std.traits : isDelegate returns false on a delegate
http://d.puremagic.com/issues/show_bug.cgi?id=5359 --- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-24 16:24:20 PST --- The real issue here was that isDelegate should have only accepted types, IOW this should have been a compile-time error not a runtime one. Fixed with https://github.com/D-Programming-Language/phobos/pull/1164 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9584] Exceptions in D are ludicrously slow (far worse than Java)
http://d.puremagic.com/issues/show_bug.cgi?id=9584 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2013-02-24 16:35:02 PST --- So, I think that it's clear that we need to take steps to improve the performance of throwing and catching exceptions. I agree. My timings on Windows 32 bit: D (latest DMD, -O -release -inline -noboundscheck): 1542590 154 ms and 259 us 69839 6 ms, 983 us, and 9 hnsecs 69741 6 ms, 974 us, and 1 hnsec 70468 7 ms, 46 us, and 8 hnsecs 70793 7 ms, 79 us, and 3 hnsecs 70539 7 ms, 53 us, and 9 hnsecs 69626 6 ms, 962 us, and 6 hnsecs Java (version 1.7.0_13), same system: 260 0ms 26us 0hnsecs 243 0ms 24us 3hnsecs 241 0ms 24us 1hnsecs 241 0ms 24us 1hnsecs 235 0ms 23us 5hnsecs 231 0ms 23us 1hnsecs 250 0ms 25us 0hnsecs -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9585] New: Implement getPair() for Associative Arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9585
Summary: Implement getPair() for Associative Arrays
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-24
16:44:21 PST ---
This was requested recently in IRC.
A getPair() function would return a key+val combination from an existing key
(ideally as a struct), e.g.:
void main()
{
string buffer = abc def;
string abc = buffer[0 .. 3];
bool[string] hash;
hash[abc] = true;
auto pair = hash.getPair(abc); // enhancement
assert(pair.key is abc); // L9
assert(pair.val == true);
// not the same as:
alias Tuple!(string, key, bool, val) Tup;
Tup tup;
tup.key = abc;
tup.val = hash[abc];
assert(tup.key is abc); // this would fail
assert(tup.val == true);
}
Note the importance of line 9, it is an 'is' check, not an equality check.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5658] Undocumented fields in std.typecons.Tuple
http://d.puremagic.com/issues/show_bug.cgi?id=5658 --- Comment #2 from github-bugzi...@puremagic.com 2013-02-24 16:48:54 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/075db4dcb9b850e64fbdb7860d6200be494feb90 issue 5658 https://github.com/D-Programming-Language/phobos/commit/2b00a2a5f9f8032f39cc70aa7e2289eb88e1447f Merge pull request #1168 from andralex/5658 Fix Issue 5658 - Undocumented fields in std.typecons.Tuple -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5658] Undocumented fields in std.typecons.Tuple
http://d.puremagic.com/issues/show_bug.cgi?id=5658 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lycus.org Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5514] Erroneous documentation and lacking randomization for topN
http://d.puremagic.com/issues/show_bug.cgi?id=5514 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lycus.org Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5514] Erroneous documentation and lacking randomization for topN
http://d.puremagic.com/issues/show_bug.cgi?id=5514 --- Comment #1 from github-bugzi...@puremagic.com 2013-02-24 16:49:26 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/7291d2e47d4a7fb17565a7d7cd04ba8f893c1a27 issue 5514 https://github.com/D-Programming-Language/phobos/commit/299cf68ecc6ee7e81c1e6a45f747c80b46fa0184 Merge pull request #1167 from andralex/5514 Fix Issue 5514 - Erroneous documentation and lacking randomization for topN -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5507] countUntil should take Ranges... instead of R2
http://d.puremagic.com/issues/show_bug.cgi?id=5507 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lycus.org Resolution||FIXED --- Comment #3 from github-bugzi...@puremagic.com 2013-02-25 01:50:17 CET --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/d7dd280e39a8f4e18b836853df7e19079e2cec62 issue 5507 https://github.com/D-Programming-Language/phobos/commit/54ddafa1a8d24e5225051280e87b0926bdbcd1ee Merge pull request #1166 from andralex/5507 Fix Issue 5507 - countUntil should take Ranges... instead of R2 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5507] countUntil should take Ranges... instead of R2
http://d.puremagic.com/issues/show_bug.cgi?id=5507 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lycus.org Resolution||FIXED --- Comment #3 from github-bugzi...@puremagic.com 2013-02-24 16:50:17 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/d7dd280e39a8f4e18b836853df7e19079e2cec62 issue 5507 https://github.com/D-Programming-Language/phobos/commit/54ddafa1a8d24e5225051280e87b0926bdbcd1ee Merge pull request #1166 from andralex/5507 Fix Issue 5507 - countUntil should take Ranges... instead of R2 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5310] Variant == const(Variant) doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=5310 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lycus.org Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5310] Variant == const(Variant) doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=5310 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lycus.org Resolution||FIXED --- Comment #1 from github-bugzi...@puremagic.com 2013-02-24 16:51:31 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/7b03c1eda59cd89739e4164235e43522269b009b issue 5310 https://github.com/D-Programming-Language/phobos/commit/75f578228cd1975995551894ca0717eb19fda0f2 Merge pull request #1163 from andralex/5310 Fix Issue 5310 - Variant == const(Variant) doesn't compile -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5924] schwartzSort of Tuple!(char)[]
http://d.puremagic.com/issues/show_bug.cgi?id=5924 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lycus.org Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9310] escapeShellCommand unittests are never run
http://d.puremagic.com/issues/show_bug.cgi?id=9310 --- Comment #1 from github-bugzi...@puremagic.com 2013-02-24 16:53:28 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/128f1e4f3a5422d893990550b8f5dc26e2d5ea13 std.process: Add an additional unit test for escapeShellCommand (issue 9310) https://github.com/D-Programming-Language/phobos/commit/71079e3901907343c27e5781a6150912782daead Merge pull request #1161 from CyberShadow/std-process-additional-unittest std.process: Add an additional unit test for escapeShellCommand (issue 9310) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5924] schwartzSort of Tuple!(char)[]
http://d.puremagic.com/issues/show_bug.cgi?id=5924 --- Comment #1 from github-bugzi...@puremagic.com 2013-02-24 16:52:47 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/48c38ddd2c17fc431056e990fd8919c6d97c4d89 Issue 5924 fix https://github.com/D-Programming-Language/phobos/commit/118d9182a908777d9776fc6aa0d704bced0a8a51 Merge pull request #1169 from andralex/5924 Fix Issue 5924 - schwartzSort of Tuple!(char)[] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5106] makeIndex should return SortedRange
http://d.puremagic.com/issues/show_bug.cgi?id=5106 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lycus.org Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5106] makeIndex should return SortedRange
http://d.puremagic.com/issues/show_bug.cgi?id=5106 --- Comment #1 from github-bugzi...@puremagic.com 2013-02-24 16:53:59 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/1a9568ce20d0fb4041bd7205483dc44636f00b1d issue 5106 https://github.com/D-Programming-Language/phobos/commit/5bbd5ef9c2aa91b5d6edeb1b386a2b9890d8e3be Merge pull request #1160 from andralex/5106 Fix Issue 5106 - makeIndex should return SortedRange -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9584] Exceptions in D are ludicrously slow (far worse than Java)
http://d.puremagic.com/issues/show_bug.cgi?id=9584 --- Comment #2 from bearophile_h...@eml.cc 2013-02-24 16:54:50 PST --- Created an attachment (id=1194) An old exception benchmark In the attach there is an old exception benchmark I have kept, it compares the same code in Java, C++, D, Python, C. On my system even Python is quite faster than D, not just Java. The C code uses longjmp/setjmp, it's not directly comparable, but it's useful for a baseline data point. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5013] std.typecons.Tuple should have constructor for static arrays
http://d.puremagic.com/issues/show_bug.cgi?id=5013 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lycus.org Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5013] std.typecons.Tuple should have constructor for static arrays
http://d.puremagic.com/issues/show_bug.cgi?id=5013 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||a...@lycus.org Resolution||FIXED --- Comment #3 from github-bugzi...@puremagic.com 2013-02-24 16:58:48 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/702daca3123caaba3c734d3d5e265c131734ecc4 issue 5013 https://github.com/D-Programming-Language/phobos/commit/35d08ef3d8e1148f2e34b3831cff8eeb649461b3 Merge pull request #1153 from andralex/5013 Fix Issue 5013 - std.typecons.Tuple should have constructor for static arrays -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9585] Implement getPair() for Associative Arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9585 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2013-02-24 17:12:27 PST --- Dupe of Issue 5466 ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9585] Implement getPair() for Associative Arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9585 --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-24 17:15:28 PST --- (In reply to comment #1) Dupe of Issue 5466 ? That's iteration, this is lookup. But you could say the two are related. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 314] [module] Static, renamed, and selective imports are always public
http://d.puremagic.com/issues/show_bug.cgi?id=314 --- Comment #42 from Marco Leise marco.le...@gmx.de 2013-02-24 17:22:23 PST --- (In reply to comment #21) In my understanding, import std.stdio : writefln; only imports the name writefln, not std and writefln. If the user wants std, he has to write static import std.stdio;. I would assume your example is invalid and is expected to fail. Why would the user do import std.stdio : writefln; if he doesn't use writefln directly? Is std.stdio.writefln the only name he's supposed to be able to use here? If yes, what the hell is the use of that? The use case is this: import std.stdio : File; import std.stream : File; ... new std.stream.File(...); There is no reason for that to fail. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7448] Documentation on etc.c.sqlite3 and etc.c.zlib left in a bad state
http://d.puremagic.com/issues/show_bug.cgi?id=7448 --- Comment #1 from Marco Leise marco.le...@gmx.de 2013-02-24 17:34:26 PST --- The dead link is fixed now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7415] dmd.X.XXX.zip ships with outdated man pages
http://d.puremagic.com/issues/show_bug.cgi?id=7415 Marco Leise marco.le...@gmx.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Marco Leise marco.le...@gmx.de 2013-02-24 17:48:12 PST --- This has been fixed in DMD-2.059. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9585] Implement getPair() for Associative Arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9585 --- Comment #3 from bearophile_h...@eml.cc 2013-02-24 18:02:39 PST --- (In reply to comment #2) That's iteration, this is lookup. But you could say the two are related. You are right, sorry. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9044] Random Previous Definition Different optlink failure (looks like a buffer overflow bug somewhere)
http://d.puremagic.com/issues/show_bug.cgi?id=9044 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #20 from Dmitry Olshansky dmitry.o...@gmail.com 2013-02-24 20:42:14 PST --- (In reply to comment #19) Can somebody confirm link failure in the last test case? I can. For me it fails with stock dmd2.062. Here is the complete log: Compiling xlib.lib... Compiling x.obj... Linking... OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html psapi.lib Warning 2: File Not Found psapi.lib xlib.lib(object) Offset 0B1ACH Record Type 0091 Error 1: Previous Definition Different : _D58C:\dmd2\windows\bin\..\..\src\druntime\import\object.di.4612__ModuleInfoZ xlib.lib(object) Offset 0B239H Record Type 00C3 Error 1: Previous Definition Different : _D58C:\dmd2\windows\bin\..\..\src\druntime\import\object.di.467__arrayZ xlib.lib(object) Offset 0B266H Record Type 00C3 Error 1: Previous Definition Different : _D58C:\dmd2\windows\bin\..\..\src\druntime\import\object.di.468__assertFiZv xlib.lib(object) Offset 0B293H Record Type 00C3 Error 1: Previous Definition Different : _D58C:\dmd2\windows\bin\..\..\src\druntime\import\object.di.4615__unittest_failFiZv Failed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1528] [tdpl] overloading template and non-template functions
http://d.puremagic.com/issues/show_bug.cgi?id=1528
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords|pull|
--- Comment #10 from Kenji Hara k.hara...@gmail.com 2013-02-24 21:32:10 PST
---
(In reply to comment #9)
https://github.com/D-Programming-Language/dmd/pull/1409
By implementing it, I found some corner cases. How should these behave?
int f1(int a, double=10) { return 1; }
int f1(int a, string=) { return 2; }
int f2(T:int)(T b, double=10) { return 1; }
int f2(T:int)(T b, string=) { return 2; }
// vs deduced parameter
int f3(int a) { return 1; }
int f3(T)(T b) { return 2; }
// vs specialized parameter
int f4(int a) { return 1; }
int f4(T:int)(T b) { return 2; }
// vs deduced parameter + template constraint (1)
int f5(int a) { return 1; }
int f5(T)(T b) if (is(T == int)) { return 2; }
// vs deduced parameter + template constraint (2)
int f6(int a) { return 1; }
int f6(T)(T b) if (is(T : int)) { return 2; }
void main()
{
f1(1); // ambiguous error
f1(1L); // ambiguous error
f2(1); // ambiguous error
f2(1L); // ambiguous error
f3(1); // ?
f3(1L); // ?
f4(1); // ?
f4(1L); // ?
f5(1); // ?
f5(1L); // ?
f6(1); // ?
f6(1L); // ?
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1528] [tdpl] overloading template and non-template functions
http://d.puremagic.com/issues/show_bug.cgi?id=1528 --- Comment #11 from Walter Bright bugzi...@digitalmars.com 2013-02-24 21:54:47 PST --- (In reply to comment #10) f3(1); // 1 f3(1L); // 2 f4(1); // ambiguous f4(1L); // ambiguous f5(1); // 1 f5(1L); // 1 f6(1); // 1 f6(1L); // 2 } The more specialized overload always wins. The constraint is not considered when evaluating which is more specialized. (Because in general we cannot evaluate that.) The constraint only determines if an overload is to be considered - it does not determine ordering. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9576] Symbol Undefined linker error on using `std.random.MinstdRand`
http://d.puremagic.com/issues/show_bug.cgi?id=9576 --- Comment #2 from Denis Shelomovskij verylonglogin@gmail.com 2013-02-25 09:12:38 MSK --- At least dmd 2.061 bundle compiles it fine. Also I'm not sure about the exact source of the problem (dmd or phobos). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1528] [tdpl] overloading template and non-template functions
http://d.puremagic.com/issues/show_bug.cgi?id=1528 --- Comment #12 from Kenji Hara k.hara...@gmail.com 2013-02-24 22:30:26 PST --- (In reply to comment #11) The more specialized overload always wins. The constraint is not considered when evaluating which is more specialized. (Because in general we cannot evaluate that.) The constraint only determines if an overload is to be considered - it does not determine ordering. Thanks for quickly answer. So, the resolution result of f5 and f6 should be same as f3, because they are identical when hide their constraints. Right? But, there is still questionable. How to calculate The more specialized overload between function template and non-template one? For example, try to consider case for f3(1). That is: 1. Normal function version f3(int) will match exactly to one int argument. 2. Function template version will deduce T - int, and then instantiated function f3!(int) == void f3(int) will match _exactly_ to one int argument. But, in general, template version is less specialized than non-template version. So, there is something necessary for ordering. --- Consider one another case for f4(1L). That is: 1. Normal function will match to one long argument with conversion (MATCHconvert). 2. Function template version will deduce T - long and then instantiated function f4!long will match exactly to one long argument. Which is specialized? In general, template version would be intended to pick up non-exact matching for generic cases. But, as far as I infer from current dmd implementation, f4(1L) will be ambiguous (template type parameter deduction without specialization always be MATCHconvert). Therefore, I'd ask question again to Walter: how does above cases behave? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9568] [64bit] wrong code for scope(exit)
http://d.puremagic.com/issues/show_bug.cgi?id=9568 --- Comment #5 from github-bugzi...@puremagic.com 2013-02-24 23:48:07 PST --- Commit pushed to fix9568 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/adf20ce10fcfec68cf74cad7aa110c3a314d45f7 fix Issue 9568 - [64bit] wrong code for scope(exit) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9568] [64bit] wrong code for scope(exit)
http://d.puremagic.com/issues/show_bug.cgi?id=9568 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2013-02-24 23:50:45 PST --- https://github.com/D-Programming-Language/dmd/pull/1689 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
