[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 --- Comment #11 from Rob Jacques 2011-12-02 21:10:23 PST --- I did some more digging. I reworked the put routine itself and changed the growth strategy to be as aggressive as the original appender. This got me down from a 52% slowdown, to a 20% slowdown. I've still have more work to do, but to put this into perspective, a 20% slowdown is equivalent to adding an extra if conditional to the put routine. Again, thanks Vladimir for these benchmarks. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7058] static initializer for structs doesn't respect init values of members
http://d.puremagic.com/issues/show_bug.cgi?id=7058
--- Comment #1 from Trass3r 2011-12-02 19:04:09 PST ---
Interestingly enough, if you add a tuple it only respects the first value at
all:
void main()
{
import std.stdio;
vec3 v = {1.5f, 1.f, 0.5f};
writeln(v);
}
template Tuple(T...)
{
alias T Tuple;
}
template Repeat(T, int count)
{
static if (!count)
alias Tuple!() Repeat;
else
alias Tuple!(T, Repeat!(T, count-1)) Repeat;
}
struct vec3
{
union
{
struct
{
float x = 0;
float y = 0;
float z = 0;
}
//float[3] cell;
Repeat!(float, 3) tuple;
}
}
$ dmd -run vector.d
vec3(1.5, nan, nan, 1.5, nan, nan)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6942] lazy parameters can break purity
http://d.puremagic.com/issues/show_bug.cgi?id=6942 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Kenji Hara 2011-12-02 18:56:15 PST --- The pureness of lazy parameter belongs to the *caller side*, not callee side. It is a design. One use case is std.exception.enforce. It receives a condition as a lazy parameter, but whole enforce function can become pure with the design. Delegate parameter is similar to lazy parameter, but it is different in this point. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7058] New: static initializer for structs doesn't respect init values of members
http://d.puremagic.com/issues/show_bug.cgi?id=7058
Summary: static initializer for structs doesn't respect init
values of members
Product: D
Version: D1 & D2
Platform: All
OS/Version: All
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: mrmoc...@gmx.de
--- Comment #0 from Trass3r 2011-12-02 18:50:33 PST ---
void main()
{
import std.stdio;
vec3 v = {1.5f, 2}; // with vec3(1.5f, 2) z becomes 0
writeln(v);
}
struct vec3
{
//union
//{
//struct
//{
float x = 0;
float y = 0;
float z = 0;
//}
//float[3] cell;
//}
}
$ dmd -run vector.d
vec3(1.5, 2, nan)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7055] to!float("INF2") == 2
http://d.puremagic.com/issues/show_bug.cgi?id=7055
Kenji Hara changed:
What|Removed |Added
Keywords||patch
Platform|Other |All
OS/Version|Windows |All
--- Comment #1 from Kenji Hara 2011-12-02 18:32:01 PST ---
https://github.com/D-Programming-Language/phobos/pull/345
"INF2" is not a complete representation of floating point number, so
to!float("INF2") should throw ConvException.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7057] New: Compiler errors on different functions on argument mismatch
http://d.puremagic.com/issues/show_bug.cgi?id=7057
Summary: Compiler errors on different functions on argument
mismatch
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic 2011-12-02
17:47:47 PST ---
struct Foo
{
void test(int) { }
void test(int, int, string, string, int) { }
}
void main()
{
Foo foo;
foo.test(0, 0, "", "");
}
test.d(10): Error: function test.Foo.test (int _param_0) is not callable using
argument types (int,int,string,string)
test.d(10): Error: expected 5 function arguments, not 4
This is extremely confusing in a library that has multiple function overloads.
The compiler first prints out the first function, but then prints out the
argument count of the second function which was the best match. It should *not*
talk about the first function at all if the second is more likely a match. The
error message should be:
test.d(10): Error: function test.Foo.test (int _param_0,int _param_1,string
_param_2,string _param_3) is not callable using argument types
(int,int,string,string)
test.d(10): Error: expected 5 function arguments, not 4
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7056] New: weird segfault in std.conv.to
http://d.puremagic.com/issues/show_bug.cgi?id=7056
Summary: weird segfault in std.conv.to
Product: D
Version: D1 & D2
Platform: All
OS/Version: All
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: mrmoc...@gmx.de
--- Comment #0 from Trass3r 2011-12-02 13:37:56 PST ---
import std.conv;
import std.math;
void main()
{
import std.stdio;
vec3 w = vec3();
writefln("%f w: %f", 3.5f, w.length);
}
struct Vector(T, int dim)
{
union
{
struct
{
T x = 0;
T y = 0;
T z = 0;
}
T[dim] cell;
}
string toString() {
return to!string(cell);
}
/// return length*length
@property T sqLength()
{
return cast()x * x + y * y + z * z;
}
/// return the vector length
@property T length() {
toString;
auto ret = sqLength;
return sqrt(ret);
}
}
alias Vector!(float, 3)vec3;
$ dmd -debug -gc vector.d && gdb --batch -ex 'run' -ex 'bt 15' ./vector
Program received signal SIGSEGV, Segmentation fault.
0x77669faa in snprintf () from /lib/x86_64-linux-gnu/libc.so.6
#0 0x77669faa in snprintf () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x0044affe in void
std.format.formatValue!(std.array.Appender!(immutable(char)[]).Appender, float,
char).formatValue(std.array.Appender!(immutable(char)[]).Appender, float, ref
std.format.FormatSpec!(char).FormatSpec) (f=0x7fffdcd8, obj=0, w=...) at
/home/trass3r/coding/dmd/linux/bin64/../../src/phobos/std/format.d:1204
#2 0x0044b387 in void
std.format.formatElement!(std.array.Appender!(immutable(char)[]).Appender,
float, char).formatElement(std.array.Appender!(immutable(char)[]).Appender,
float, ref std.format.FormatSpec!(char).FormatSpec) (f=0x7fffdcd8, val=0,
w=...) at
/home/trass3r/coding/dmd/linux/bin64/../../src/phobos/std/format.d:1596
#3 0x0044a661 in void
std.format.formatRange!(std.array.Appender!(immutable(char)[]).Appender,
float[], char).formatRange(std.array.Appender!(immutable(char)[]).Appender,
float[], ref std.format.FormatSpec!(char).FormatSpec) (f=0x7fffdcd8,
val=0x7fffdd780003, w=...) at
/home/trass3r/coding/dmd/linux/bin64/../../src/phobos/std/format.d:1452
#4 0x0044a50f in void
std.format.formatValue!(std.array.Appender!(immutable(char)[]).Appender,
float[], char).formatValue(std.array.Appender!(immutable(char)[]).Appender,
float[], ref std.format.FormatSpec!(char).FormatSpec) (f=0x7fffdcd8,
val=0x7fffdd780003, w=...) at
/home/trass3r/coding/dmd/linux/bin64/../../src/phobos/std/format.d:1386
#5 0x0044a4dd in immutable(char)[] std.conv.toStr!(immutable(char)[],
float[]).toStr(float[]) (src=0x7fffdd780003) at
/home/trass3r/coding/dmd/linux/bin64/../../src/phobos/std/conv.d:94
#6 0x0044a48f in immutable(char)[] std.conv.toImpl!(immutable(char)[],
float[]).toImpl(float[]) (s=0x7fffdd780003) at
/home/trass3r/coding/dmd/linux/bin64/../../src/phobos/std/conv.d:803
#7 0x0044a401 in immutable(char)[] std.conv.toImpl!(immutable(char)[],
float[3]).toImpl(ref float[3]) (s=0x7fffdd78) at
/home/trass3r/coding/dmd/linux/bin64/../../src/phobos/std/conv.d:353
#8 0x0044a381 in immutable(char)[]
std.conv.to!(immutable(char)[]).to!(float[3]).to(float[3]) (_param_0=...) at
/home/trass3r/coding/dmd/linux/bin64/../../src/phobos/std/conv.d:237
#9 0x00442d3f in immutable(char)[] vector.Vector!(float,
3).Vector.toString() (this=0x7fffde10) at vector.d:25
#10 0x00442df6 in @property float vector.Vector!(float,
3).Vector.length() (this=0x7fffde10) at vector.d:36
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 --- Comment #10 from Rob Jacques 2011-12-02 12:35:48 PST --- (In reply to comment #9) > I did some benchmarks with this and some other variants. > > At least for small strings, this code performs worse than the current > appender. > Judging by the description it's optimized for large blocks of data, but in the > case of many small strings it can perform as bad as 50% worse than the current > appender for typical cases (e.g. building a few KB of HTML). > > Here is my test code: > > http://dump.thecybershadow.net/a05a2c4dc7cd2a8e21b3a447c7eff150/test2.d > http://dump.thecybershadow.net/eff5c7ef81e18bf75d8462ffe16a52e4/appender.d > > I was able to get 25% more performance for my test case from the standard > appender by adding a method that accepts multiple arguments (which > preallocates > only once). My code is a hack, but it would be nice to see something like that > in the official appender. Thank you for the additional benchmarks. The primary purpose of my code was to optimize for memory usage, which in turn optimizes for computation/performance (i.e. number of main memory copies and memory allocations). And, I also optimized appender for use as a dynamic buffer. But this is all big-O stuff. I did include a short string test in my benchmark set while I was optimizing the code; my first implementations (never posted) did have some major slow downs, which I fixed by re-working the put routine. So there still might still be some little-o issues there. And I will definitely add a void put(U...)(U items) overload. I don't think it would affect this benchmark in any ways, but my appender is somewhat dependent on my patch to put (Issue 5233). I've run your benchmarks and played with them a little bit. Running the benchmarks sequentially is definitely generating GC warm-up issues. I've recommend running them cold in the future, though the qualitative results are the same and cold runs are the ideal situation for the old appender. I want to rewrite my __ctfe version appender, since Don added support for structs and new, so I'll also look at the short string performance of appender while I'm at it I'll do some profiling and look into this some more. I'd really like for appender to be the right solution for anything bigger than `hello` ~ `world`. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7024] inconsistent mangling of shared in extern(C++)
http://d.puremagic.com/issues/show_bug.cgi?id=7024
--- Comment #7 from d...@dawgfoto.de 2011-12-02 12:22:18 PST ---
The baseline of D type system is to disallow things that can't be guaranteed.
C++ definitely can't guarantee any of the three.
To avoid explicit casting at every caller place, you could add
a D wrapper that does the calling.
extern(C++) void _spawn(void function() fun, void* data);
void spawn(extern(C++) void function() fun, shared void* data)
{
_spawn(fun, cast(void*)data);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7055] New: to!float("INF2") == 2
http://d.puremagic.com/issues/show_bug.cgi?id=7055
Summary: to!float("INF2") == 2
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha 2011-12-02 11:21:18 PST ---
import std.stdio, std.conv;
void main() {
writeln(to!float("INF2")); // Prints 2
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7054] New: formatting fixed width string fields w/utf
http://d.puremagic.com/issues/show_bug.cgi?id=7054
Summary: formatting fixed width string fields w/utf
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P5
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: brad.lanam.c...@gmail.com
--- Comment #0 from Brad L 2011-12-02 11:00:52 PST
---
Using a width specifier in conjunction with a utf string fails. It would be
nice to have a %S modifier that handles this situation.
123456789012345
Gr��e: incorrect
Gr��e: correct
Gr��e : incorrect
Gr��e : correct
Gr� : incorrect
Gr�� : correct
import std.stdio;
import std.string;
import std.utf : count;
void
main (string[] args)
{
string t = "Gr��e";
size_t width = 10;
auto len = t.length;
auto utflen = std.utf.count (t);
auto tlen = width + len - utflen;
writefln ("123456789012345");
writefln ("%10s: incorrect", t);
writefln ("%*s: correct", tlen, t);
writefln ("%-10s: incorrect", t);
writefln ("%-*s: correct", tlen, t);
writefln ("%-10.4s: incorrect", t);
auto fmt = format ("%%-%d.%ds: correct", tlen, tlen - 6);
writefln (fmt, t);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7024] inconsistent mangling of shared in extern(C++)
http://d.puremagic.com/issues/show_bug.cgi?id=7024
--- Comment #6 from deadalnix 2011-12-02 10:59:31 PST ---
(In reply to comment #4)
> Rather than trying to fix the C++ mangling, wouldn't it make more sense to
> disallow 'shared' in extern(C++) declarations?
As thoses concept doesn't exists in C++, this is up to the C++ programmer to
ensure that something is shared or not. Sometime, C++ code is just made to
handle shared data, it is just not explicit.
In this case, you ends up using convoluted casts to handle everything.
I have a practical case : start a thread from C++, but that could interract
with D (so you must go throw D's way of starting thread). You end up writing
something like this :
alias extern(C++) void* function(void*) EntryPoint;
extern(C++) void* D_start_thread(EntryPoint entryPoint, void* userData) {
Tid tid = spawn(function void(EntryPoint entryPoint, shared void* userData)
{
entryPoint(cast(void*) userData);
}, entryPoint, cast(shared void*) userData);
return cast(void*) [tid].ptr;
}
So I would recommand to ignore shared in mangling of C++ function and mangle
immutable as const. It is up to the programmer to ensure that thoses are right
qualifiers.
inout can't be handled nicely so it should generate a compile time error.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7053] New: inout implicit conversion error
http://d.puremagic.com/issues/show_bug.cgi?id=7053
Summary: inout implicit conversion error
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: wfunct...@hotmail.com
--- Comment #0 from wfunct...@hotmail.com 2011-12-02 10:36:23 PST ---
inout() should NOT be treated as a type constructor, which changes the return
type:
class C(T) { inout this(inout(T)) { } }
C!T slice(T)(auto ref T c) { return new C!T(c); }
void main() { [1, 2, 3, 4, 5].slice(); }
//Test.d(2): Error: cannot implicitly convert expression (new C(items))
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 --- Comment #9 from Vladimir Panteleev 2011-12-02 10:33:44 PST --- I did some benchmarks with this and some other variants. At least for small strings, this code performs worse than the current appender. Judging by the description it's optimized for large blocks of data, but in the case of many small strings it can perform as bad as 50% worse than the current appender for typical cases (e.g. building a few KB of HTML). Here is my test code: http://dump.thecybershadow.net/a05a2c4dc7cd2a8e21b3a447c7eff150/test2.d http://dump.thecybershadow.net/eff5c7ef81e18bf75d8462ffe16a52e4/appender.d I was able to get 25% more performance for my test case from the standard appender by adding a method that accepts multiple arguments (which preallocates only once). My code is a hack, but it would be nice to see something like that in the official appender. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7051] Class member with un-@safe destructor gives confusing error
http://d.puremagic.com/issues/show_bug.cgi?id=7051 --- Comment #3 from timon.g...@gmx.ch 2011-12-02 10:11:46 PST --- Actually I think it is undocumented, but Andrei might have mentioned it in one of his articles iirc. SafeD is generally underspecified. But I think @safe should certainly transitively apply to members. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7051] Class member with un-@safe destructor gives confusing error
http://d.puremagic.com/issues/show_bug.cgi?id=7051 --- Comment #2 from klickverbot 2011-12-02 09:59:08 PST --- @Timon: Yes, that's the intuitive meaning of it, but is this actually documented somewhere? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7051] Class member with un-@safe destructor gives confusing error
http://d.puremagic.com/issues/show_bug.cgi?id=7051 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #1 from timon.g...@gmx.ch 2011-12-02 09:56:21 PST --- a @safe class is a class that has only safe members. This design minimizes the annotation overhead for safe code, because you can mark every function and method in a module as @safe simply by writing @safe: at the top. The error message should certainly be improved though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7052] New: @system on @safe class methods inconsistency
http://d.puremagic.com/issues/show_bug.cgi?id=7052
Summary: @system on @safe class methods inconsistency
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@klickverbot.at
--- Comment #0 from klickverbot 2011-12-02 09:55:41 PST
---
Consider:
---
void unsafe() {}
@safe class Foo {
void bar() @system {
unsafe();
}
}
---
DMD 2.057 Git (887dda0ba) fails with:
---
Error: safe function 'bar' cannot call system function 'unsafe'
---
The following two examples compile, however (note the different position of
@system in the first example):
---
void unsafe() {}
@safe class Foo {
@system void bar() {
unsafe();
}
}
---
---
void unsafe() {}
@safe class Foo {
void bar() @trusted {
unsafe();
}
}
---
Given that the effects of @safe being applied to classes don't seem to be
mentioned in the spec, this is technically not a rejects-valid bug, but
certainly very inconsistent.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7051] New: Class member with un-@safe destructor gives confusing error
http://d.puremagic.com/issues/show_bug.cgi?id=7051
Summary: Class member with un-@safe destructor gives confusing
error
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@klickverbot.at
--- Comment #0 from klickverbot 2011-12-02 09:30:38 PST
---
Consider:
---
struct Foo {
~this() {}
}
@safe {
class Bar {
Foo f;
}
}
---
DMD 2.057 Git (887dda0ba) fails with:
---
Error: safe function '~this' cannot call system function '~this'
---
I didn't think about what the best solution for this yet (what exactly is a
�safe class� in the first place?), but the error message should certainly be
improved.
[related to issue 7050]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7050] New: Safety error message should include full function names
http://d.puremagic.com/issues/show_bug.cgi?id=7050
Summary: Safety error message should include full function
names
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@klickverbot.at
--- Comment #0 from klickverbot 2011-12-02 09:14:16 PST
---
Currently (DMD 2.057 Git, 887dda0ba),
---
struct Foo {
this (int a) {}
}
@safe void foo() {
auto f = Foo(3);
}
---
produces
---
Error: safe function 'foo' cannot call system function 'this'
---
.
The error message should include the type (i.e. Foo.this) so it is clear what
it refers to.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7049] Multiple scope(failure) blocks don't work in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=7049 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis 2011-12-02 08:54:17 PST --- That's odd. That would imply that the try-catch blocks generated by scope(failure) are using catch(Throwable) instead of catch(Exception), but scope statements are supposed to be skipped when Errors are thrown, so there's no reason for them be catching Throwable instead of Exception. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7049] New: Multiple scope(failure) blocks don't work in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=7049
Summary: Multiple scope(failure) blocks don't work in @safe
code
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@klickverbot.at
--- Comment #0 from klickverbot 2011-12-02 08:49:46 PST
---
---
@safe void foo() {
scope (failure) {}
scope (failure) {}
}
---
DMD 2.057 Git (887dda0ba) gives:
---
Error: can only catch class objects derived from Exception in @safe code, not
'object.Throwable'
Error: undefined identifier __o1300
---
The reason for this are the artificial try/catch blocks generated around
statement.c:530.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7046] CTFE: append null does nothing
http://d.puremagic.com/issues/show_bug.cgi?id=7046 --- Comment #7 from Adam D. Ruppe 2011-12-02 07:53:36 PST --- BTW, I labeled this as CTFE because in 2.056, running the same function at runtime, the assert passes. I think this worked in CTFE a couple releases ago too, and since it works in the git version again, it was probably just a temporary regression in the interpreter. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7046] CTFE: append null does nothing
http://d.puremagic.com/issues/show_bug.cgi?id=7046 --- Comment #6 from Adam D. Ruppe 2011-12-02 07:47:17 PST --- (In reply to comment #2) > I mean a null could mean a null string[], not a null string. I oversimplified the test - in the original code it came from, it was more like string a = null; ret ~= a; which gets the same result in 2.056 I haven't tried git though. I'm not sure how to use that yet! > I almost think the code in question should fail to compile for being too > ambiguous. With null itself... maybe. In the case of string[], ~= null could have two meanings, but one of them is pretty obviously a no-op, so it's probably not what you meant. If a variable happens to be null, maybe doing nothing is what you wanted, but in that case, the variable has an exact type declared so it's not ambiguous anymore. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 --- Comment #8 from Rob Jacques 2011-12-02 05:38:25 PST --- I'm planning on putting in a pull request for this, probably sometime over the Christmas holidays(I hope). Currently, I'm in the middle of finishing up my Ph.D. thesis and moving to a new city and job, so my bandwidth is very limited at the moment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7006] std.math.pow (integral, integral) crashes on negative exponents
http://d.puremagic.com/issues/show_bug.cgi?id=7006
--- Comment #3 from Don 2011-12-02 05:01:01 PST ---
(In reply to comment #2)
> That is like saying 1/2 should give a div by zero error because the result
> does
> not fit in an integer and therefore it must always indicate a bug.
Accidental use of integer division instead of floating point division is a
very, very common bug.
> I want this:
>
> assert(a ^^ -1 == 1/a);
Why do you want that? Do you have any use cases where it's not a bug?
> This is only div by zero if a is zero.
>
>
> (BTW: This does not give a div by zero error on my x86 machine, and I have no
> clue why you think it should: void main(){auto x = -1; x = x/(x-int.max);})
Sorry, got it upside down. It's -int.max -1, divided by -1.
This generates a hardware division error. Depending on the OS, your OS may
inspect the operands to determine if it is a div by zero, or this special case:
void main(){auto x = 1; x = (-1-int.max)/-x;}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7046] CTFE: append null does nothing
http://d.puremagic.com/issues/show_bug.cgi?id=7046 --- Comment #5 from Steven Schveighoffer 2011-12-02 04:54:29 PST --- (In reply to comment #3) > See bug 2006. So is this a dupe? I'm concerned there was a change in git that makes this "work." Moving from one ambiguous interpretation to another doesn't sound like progress. Do we have some definitive answer on what *should* happen? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 --- Comment #7 from Steven Schveighoffer 2011-12-02 04:49:25 PST --- I think we were waiting on Rob to change this into a pull request. Not sure if that's going to happen? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7046] CTFE: append null does nothing
http://d.puremagic.com/issues/show_bug.cgi?id=7046 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc 2011-12-02 04:48:35 PST --- (In reply to comment #2) > I almost think the code in question should fail to compile for being too > ambiguous. Right. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7046] CTFE: append null does nothing
http://d.puremagic.com/issues/show_bug.cgi?id=7046 --- Comment #3 from Don 2011-12-02 04:44:28 PST --- See bug 2006. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7046] CTFE: append null does nothing
http://d.puremagic.com/issues/show_bug.cgi?id=7046 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer 2011-12-02 04:30:34 PST --- Are we sure this isn't expected? I mean a null could mean a null string[], not a null string. string[] ret; string[] a = null; ret ~= a; ret ~= a; neither of these lines should do anything to ret, since they are empty arrays of the same type. I almost think the code in question should fail to compile for being too ambiguous. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7046] CTFE: append null does nothing
http://d.puremagic.com/issues/show_bug.cgi?id=7046 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 2011-12-02 02:57:40 PST --- This works on git HEAD. Probably a duplicate of a recently fixed bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7043] CTFE: ICE illegal reference value 0LU, only with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=7043
--- Comment #3 from Don 2011-12-02 02:52:02 PST ---
Further reduced. Still requires -inline.
bool bug7043(S)(ref int x) {
return true;
}
static assert( {
int i = 0;
return bug7043!(char)(i);
}() );
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #6 from Vladimir Panteleev 2011-12-02 02:45:59 PST --- What's this status of this patch? Note that today, it's extremely unlikely for patches from Bugzilla to be incorporated unless someone creates a GitHub pull request for them. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7043] CTFE: ICE illegal reference value 0LU, only with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=7043
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
Summary|CTFE: ICE illegal reference |CTFE: ICE illegal reference
|value 0LU |value 0LU, only with
||-inline
--- Comment #2 from Don 2011-12-02 02:41:53 PST ---
Reduced test case, requires -inline:
bool decode(S)(ref int x) {
return true;
}
bool front(A)() {
int i = 0;
return decode!(char)(i);
}
static assert( is(typeof({ front!(int)(); }())) );
static assert ( front!(int)());
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7048] New: Problem with out fixed-sized matrix
http://d.puremagic.com/issues/show_bug.cgi?id=7048
Summary: Problem with out fixed-sized matrix
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-12-02 01:43:16 PST ---
void foo(out int[2][2] n) {}
void main() {
int[2][2] m;
foo(m);
}
DMD 2.057head:
test.d(1): Error: cannot implicitly convert expression (0) of type int to
int[2u][]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
