[Issue 2717] alloca(0) leaves stack unaligned on OSX
http://d.puremagic.com/issues/show_bug.cgi?id=2717 Lionello Lunesu 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 10451] Array of pointers to opaque struct gives forward reference errors.
http://d.puremagic.com/issues/show_bug.cgi?id=10451 --- Comment #4 from Manu 2013-08-31 23:00:46 PDT --- (In reply to comment #3) > Manu meant this: :) > > http://d.puremagic.com/issues/show_bug.cgi?id=10766 Haha, thx ;) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10451] Array of pointers to opaque struct gives forward reference errors.
http://d.puremagic.com/issues/show_bug.cgi?id=10451 Ali Cehreli changed: What|Removed |Added CC||acehr...@yahoo.com --- Comment #3 from Ali Cehreli 2013-08-31 20:05:39 PDT --- Manu meant this: :) http://d.puremagic.com/issues/show_bug.cgi?id=10766 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5849] std.random.dice is better as a range
http://d.puremagic.com/issues/show_bug.cgi?id=5849 --- Comment #9 from bearophile_h...@eml.cc 2013-08-31 19:47:44 PDT --- Also, why is the random generator engine the first optional argument of dice(), while it's the last for uniform()? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10938] New: ICE on recursive instantiation in opDispatch
http://d.puremagic.com/issues/show_bug.cgi?id=10938
Summary: ICE on recursive instantiation in opDispatch
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: ice
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic 2013-08-31
18:38:28 PDT ---
-
class C
{
this()
{
this.opts["opts"] = 1;
}
auto opDispatch(string field : "opts")()
{
return this.opts; // should likely be a CT error instead
}
}
void main()
{
}
-
Stack trace:
0018e610 00497af9 image0040!FuncDeclaration::semantic3+0x1612
[C:\dmd-git\dmd2\src\dmd\src\func.c @ 1281]
0018e648 004951ee image0040!TemplateInstance::semantic3+0xe9
[C:\dmd-git\dmd2\src\dmd\src\template.c @ 6915]
0018e680 00495c6f image0040!TemplateInstance::trySemantic3+0x79
[C:\dmd-git\dmd2\src\dmd\src\template.c @ 5319]
0018e790 00494fd5 image0040!TemplateInstance::semantic+0xa20
[C:\dmd-git\dmd2\src\dmd\src\template.c @ 5725]
0018e7a4 00418a8f image0040!TemplateInstance::semantic+0x14
[C:\dmd-git\dmd2\src\dmd\src\template.c @ 5246]
0018e8d8 0042eaf4 image0040!DotTemplateInstanceExp::semanticY+0x337
[C:\dmd-git\dmd2\src\dmd\src\expression.c @ 8125]
0018e948 0043c033 image0040!Type::noMember+0x290
[C:\dmd-git\dmd2\src\dmd\src\mtype.c @ 2240]
0018ebb4 00417b74 image0040!TypeClass::dotExp+0x974
[C:\dmd-git\dmd2\src\dmd\src\mtype.c @ 8717]
0018ece4 00416c55 image0040!DotIdExp::semanticY+0xb07
[C:\dmd-git\dmd2\src\dmd\src\expression.c @ 7722]
0018ed00 00420e45 image0040!DotIdExp::semantic+0x14
[C:\dmd-git\dmd2\src\dmd\src\expression.c @ 7391]
0018f070 004ce5bd image0040!AssignExp::semantic+0x10a
[C:\dmd-git\dmd2\src\dmd\src\expression.c @ 11046]
0018f090 004cee1e image0040!ExpStatement::semantic+0x28
[C:\dmd-git\dmd2\src\dmd\src\statement.c @ 385]
0018f258 004a279e image0040!CompoundStatement::semantic+0xcd
[C:\dmd-git\dmd2\src\dmd\src\statement.c @ 623]
0018fa24 004bf9d1 image0040!FuncDeclaration::semantic3+0x13c1
[C:\dmd-git\dmd2\src\dmd\src\func.c @ 1255]
0018fa9c 00440914 image0040!AggregateDeclaration::semantic3+0x9c
[C:\dmd-git\dmd2\src\dmd\src\struct.c @ 130]
0018facc 004051c5 image0040!Module::semantic3+0xc1
[C:\dmd-git\dmd2\src\dmd\src\module.c @ 812]
0018ff0c 00405a61 image0040!tryMain+0x2c67
[C:\dmd-git\dmd2\src\dmd\src\mars.c @ 1512]
0018ff48 0057ae2d image0040!main+0x43 [C:\dmd-git\dmd2\src\dmd\src\mars.c @
1725]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10937] New: struct inside union gives uninitialized error in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10937
Summary: struct inside union gives uninitialized error in CTFE
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: destructiona...@gmail.com
--- Comment #0 from Adam D. Ruppe 2013-08-31
18:29:57 PDT ---
===
struct Test {
union {
ubyte[1] a;
struct {
ubyte b;
}
}
this(ubyte B) {
this.b = B; // this triggers the error below
// this.a[0] = B; // this works
}
}
enum test = Test(0); // test30.d(9): Error: uninitialized variable 'b' cannot
be returned from CTFE
===
Both constructor lines work fine at runtime.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5849] std.random.dice is better as a range
http://d.puremagic.com/issues/show_bug.cgi?id=5849
--- Comment #8 from bearophile_h...@eml.cc 2013-08-31 17:47:46 PDT ---
(In reply to comment #7)
> import std.stdio, std.random, std.range;
> void main() {
> immutable probabilities = [0.2, 0.6, 0.1, 0.1];
> immutable values = "ACGT";
> probabilities.diceRange(values).take(10).writeln;
> }
>
>
> This is quite handy.
If the second optional argument is not supported, then the code becomes:
import std.stdio, std.random, std.range;
void main() {
immutable probabilities = [0.2, 0.6, 0.1, 0.1];
immutable values = "ACGT";
probabilities.diceRange.map!(i => values[i]).take(10).writeln;
}
But I am not sure it's strictly equivalent.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10766] Variant does not accept pointers to incomplete (opaque) types
http://d.puremagic.com/issues/show_bug.cgi?id=10766 --- Comment #2 from Manu 2013-08-31 17:45:38 PDT --- http://d.puremagic.com/issues/show_bug.cgi?id=10451 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10451] Array of pointers to opaque struct gives forward reference errors.
http://d.puremagic.com/issues/show_bug.cgi?id=10451 Manu changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #2 from Manu 2013-08-31 17:45:25 PDT --- http://d.puremagic.com/issues/show_bug.cgi?id=10451 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5849] std.random.dice is better as a range
http://d.puremagic.com/issues/show_bug.cgi?id=5849
--- Comment #7 from bearophile_h...@eml.cc 2013-08-31 17:44:25 PDT ---
If we don't want to break the API of dice() making it a range, a simple
solution is to call the dice range "diceRange" and keep both (but perhaps dice
becomes a small function that returns diceRange.front).
Another interesting suggestion: in my code I've seen that most times I want to
use a dice/diceRange I have to map its result on the items of an array:
import std.stdio, std.random;
void main() {
immutable probabilities = [0.2, 0.6, 0.1, 0.1];
immutable values = "ACGT";
foreach (_; 0 .. 10)
values[probabilities.dice].write;
}
That outputs something similar to:
CGCCAAACCC
So an improvement for diceRange() is to accept as first argument the range of
probabilities, and as second optional argument a range of items. If the second
argument is not given, then it generates integers as dice(). If the second
argument is given, then it yields the items, according to their probabilities.
So that program becomes:
import std.stdio, std.random, std.range;
void main() {
immutable probabilities = [0.2, 0.6, 0.1, 0.1];
immutable values = "ACGT";
probabilities.diceRange(values).take(10).writeln;
}
This is quite handy.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10766] Variant does not accept pointers to incomplete (opaque) types
http://d.puremagic.com/issues/show_bug.cgi?id=10766 Manu changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #1 from Manu 2013-08-31 17:43:23 PDT --- Same issue perhaps? struct MyStruct; MyStruct*[] arrayOfPointers; arrayOfPointers ~= null; // fail arrayOfPointers = new MyStruct*[n]; // also fail Complains: Error: struct MyStruct is forward referenced when looking for 'toHash' Error: struct MyStruct is forward referenced when looking for 'opCmp' Error: struct MyStruct is forward referenced when looking for 'toString' Error: struct MyStruct unknown size Error: struct MyStruct no size yet for forward reference Error: struct MyStruct unknown size Error: struct MyStruct no size yet for forward reference -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10819] Invalid comparison for equality of lambda functions
http://d.puremagic.com/issues/show_bug.cgi?id=10819 --- Comment #9 from Andrei Alexandrescu 2013-08-31 16:12:26 PDT --- Yah, a hash-based solution would be quite good. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10819] Invalid comparison for equality of lambda functions
http://d.puremagic.com/issues/show_bug.cgi?id=10819 --- Comment #8 from hst...@quickfur.ath.cx 2013-08-31 15:32:59 PDT --- Hmm you're right. We can't drop the module, otherwise lambdas with static variables will be wrongly conflated. :-/ But is this still doable for lambdas within the same module? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10466] Optional "[]" syntax for std.range.iota too
http://d.puremagic.com/issues/show_bug.cgi?id=10466 --- Comment #8 from Joseph Rushton Wakeling 2013-08-31 12:37:42 PDT --- (In reply to comment #7) > I understand the general meaning of your words, and I could agree, but at the > moment there is no D code around shaped as "iota!"(]"(0.0, 1.0, 0.3)", so > formally there is no breaking. A code breaking change is when code that used > to > work suddenly stops working or silently has a different semantics. No, but there is D code shaped around iota(0.0, 1.0, 0.3) which is semantically identical to iota!"[)"(0.0, 1.0, 0.3), which is part of the proposal. So, if there is going to be any "choice of boundary conditions" generalization of iota, it should work as a seamless generalization of all the behaviour it currently supports -- which includes both integral and floating-point types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10936] unittest in struct body makes crash dmd
http://d.puremagic.com/issues/show_bug.cgi?id=10936 --- Comment #1 from Oleg B 2013-08-31 11:33:54 PDT --- I want say UNCOMMENT 11,12 lines -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10936] New: unittest in struct body makes crash dmd
http://d.puremagic.com/issues/show_bug.cgi?id=10936
Summary: unittest in struct body makes crash dmd
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: code.via...@gmail.com
--- Comment #0 from Oleg B 2013-08-31 11:31:52 PDT ---
[code]
struct vec( size_t N, string AS="" )
{
float[N] data;
this(E)( E[] ext... ) { data[0] = 0; }
@property auto opDispatch(string v)() const
{ mixin( "return vec!(v.length,v)( 0 );" ); }
unittest {
auto pos = vec!(3,"xyz")( 1, 2, 10 );
//auto pxx = pos.xy;
//assert( is( typeof( pxy ) == vec!(2,"xy") ) );
assert( is( typeof( pos.xy ) == vec!(2,"xy") ) );
}
}
unittest { vec!(3,"xyz") a; }
[/code]
if unittest in struct body I have error:
dmd: func.c:1299: virtual void FuncDeclaration::semantic3(Scope*): Assertion
`type == f' failed.
if uncomment 11,12 lines and comment I have error:
dmd: struct.c:741: virtual void StructDeclaration::semantic(Scope*): Assertion
`type->ty != Tstruct || ((TypeStruct *)type)->sym == this' failed.
if unittest take away from a body I haven't dmd errors
[code]
struct vec( size_t N, string AS="" )
{
float[N] data;
this(E)( E[] ext... ) { data[0] = 0; }
@property auto opDispatch(string v)() const
{ mixin( "return vec!(v.length,v)( 0 );" ); }
}
unittest { vec!(3,"xyz") a; }
unittest {
auto pos = vec!(3,"xyz")( 1, 2, 10 );
auto pxx = pos.xy;
assert( is( typeof( pxy ) == vec!(2,"xy") ) );
assert( is( typeof( pos.xy ) == vec!(2,"xy") ) );
}
[/code]
i use:
$ dmd -unittest -main file.d
system:
$ uname -a
Linux lenovo 3.9.11-200.fc18.x86_64 #1 SMP Mon Jul 22 21:04:50 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
DMD64 D Compiler v2.063.2
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10935] New: Malformed std.windows.charset reference
http://d.puremagic.com/issues/show_bug.cgi?id=10935 Summary: Malformed std.windows.charset reference Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: temta...@gmail.com --- Comment #0 from Temtaime 2013-08-31 10:47:36 PDT --- http://dlang.org/phobos/std_windows_charset.html Looks ugly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10934] New: D logo missing when building website on Windows
http://d.puremagic.com/issues/show_bug.cgi?id=10934 Summary: D logo missing when building website on Windows Product: D Version: D2 Platform: All OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2013-08-31 04:54:49 PDT --- When I do a 'make -f win32.mak function.html', the D logo is missing, instead there's "D LOGO" text with a file url "file:///" -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10555] enumerator can no longer increment beyond maximum of initializer
http://d.puremagic.com/issues/show_bug.cgi?id=10555
--- Comment #4 from Henning Pohl 2013-08-31 04:23:52
PDT ---
Keep in mind that you can always cast to the base type:
enum A // int
{
A0
}
template BaseType(E)
{
static if (is(E e == enum))
{
alias BaseType = e;
}
else
{
static assert("not an enum");
}
}
enum B // int
{
B0 = cast(BaseType!A)A.A0,
B1
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10555] enumerator can no longer increment beyond maximum of initializer
http://d.puremagic.com/issues/show_bug.cgi?id=10555
Henning Pohl changed:
What|Removed |Added
CC||henn...@still-hidden.de
--- Comment #3 from Henning Pohl 2013-08-31 04:16:03
PDT ---
I think this behaviour is correct:
Spec:
If the EnumBaseType is not explicitly set, and the first EnumMember has an
initializer, it is set to the type of that initializer. Otherwise, it defaults
to type int.
Named enum members may not have individual Types.
A named enum member can be implicitly cast to its EnumBaseType, but
EnumBaseType types cannot be implicitly cast to an enum type.
The behaviour before issue 3096 always used int as EnumBaseType even though
there is a first initializer.
enum A // int
{
A0
}
enum B // A
{
B0 = A.A0,
B1
}
In this case the base type of B is A and A does not have a member whith a value
of 1.
enum A // int
{
A0
}
enum B // A
{
B0 = A.A0,
B1 = A.A0 + 1
}
This is basically the same case as above.
enum A // int
{
A0
}
enum B // int
{
B0 = A.A0 + 0,
B1
}
This works because the type of the first initializer is int. So the base type
of B becomes int and ints can be incremented easily.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10819] Invalid comparison for equality of lambda functions
http://d.puremagic.com/issues/show_bug.cgi?id=10819 --- Comment #7 from Peter Alexander 2013-08-31 03:53:53 PDT --- (In reply to comment #6) > This is probably total overkill, but what about instead of mangling to > __lambda > + an incrementing integer, replace the integer with the SHA hash of the > lambda's AST tree? As Andrei said, we cater only to the case where the two > lambdas are token-for-token identical, because the general problem of > equivalence between two arbitrary lambdas is uncomputable. That works but is it OK for the lambda type to not have a module? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10466] Optional "[]" syntax for std.range.iota too
http://d.puremagic.com/issues/show_bug.cgi?id=10466 --- Comment #7 from bearophile_h...@eml.cc 2013-08-31 03:25:36 PDT --- (In reply to comment #6) > Bottom line -- iota() currently does allow FP numbers and excluding them would > be a breaking change. I understand the general meaning of your words, and I could agree, but at the moment there is no D code around shaped as "iota!"(]"(0.0, 1.0, 0.3)", so formally there is no breaking. A code breaking change is when code that used to work suddenly stops working or silently has a different semantics. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10230] Duplicated buttons for runnable examples
http://d.puremagic.com/issues/show_bug.cgi?id=10230 --- Comment #2 from github-bugzi...@puremagic.com 2013-08-31 02:50:23 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/87bd3315db559ecca11e3bf69ac0410a16da7d8b fix Issue 10230 - Duplicated buttons for runnable examples https://github.com/D-Programming-Language/phobos/commit/aa3b13ce49c84c6cae35541c72a4f44d785c49f9 Merge pull request #1328 from 9rnsr/fix10230 Issue 10230 - Duplicated buttons for runnable examples -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10919] typeof should accept types
http://d.puremagic.com/issues/show_bug.cgi?id=10919 Temtaime changed: What|Removed |Added CC||temta...@gmail.com --- Comment #3 from Temtaime 2013-08-31 01:45:50 PDT --- I'm agree with Timon. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10893] Numerous DDoc parameter warnings in Phobos (as found by 10236)
http://d.puremagic.com/issues/show_bug.cgi?id=10893 Lionello Lunesu changed: What|Removed |Added Keywords||pull --- Comment #2 from Lionello Lunesu 2013-08-31 00:43:25 PDT --- https://github.com/D-Programming-Language/phobos/pull/1536 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10466] Optional "[]" syntax for std.range.iota too
http://d.puremagic.com/issues/show_bug.cgi?id=10466 Joseph Rushton Wakeling changed: What|Removed |Added CC||joseph.wakel...@webdrake.ne ||t --- Comment #6 from Joseph Rushton Wakeling 2013-08-31 00:34:59 PDT --- (In reply to comment #4) > Hmm, iota with FP gets tricky, because, for example, 0.1 does not have an > exact > representation in floating-point. So if you write iota(0.0, 1.0, 0.1), it's > unclear whether 1.0 will be included or not (for example, you may end up with > 0.8 and it gets included, or it may end up with 1.001 and get > excluded). Surely that should be a case of, "use with FP at own risk". There are cases where it might be useful, but as with all things, you need to understand the possibility of rounding error. I got bitten rather amusingly by such an example where I was doing a for () loop across [0, 1] in 0.1 increments. GDC and LDC can handle that, DMD couldn't, and I had to switch to increments that were negative powers of 2. If you can trust the user to implement a for () loop correctly, you can trust them to do the same with iota(). Bottom line -- iota() currently does allow FP numbers and excluding them would be a breaking change. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10881] Support %f formatting for a std.complex.complex
http://d.puremagic.com/issues/show_bug.cgi?id=10881 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #12 from monarchdo...@gmail.com 2013-08-31 00:20:49 PDT --- (In reply to comment #11) > (In reply to comment #10) > > Commit pushed to master at https://github.com/D-Programming-Language/phobos > > Now using this formatting string, for the given matrix: > "[%([%(%1.3f, %)],\n %)]]" > > It outputs: > > [[0.707+0.000i, 0.707+0.000i, 0.000+0.000i], > [0.000-0.707i, 0.000+0.707i, 0.000+0.000i], > [0.000+0.000i, 0.000+0.000i, 0.000+1.000i]] For anybody reading this on forum.dlang.org: please view the entry on the bug tracker: There *is* a space that prefixes those lines, and they are all actually perfectly aligned. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
