[Issue 10711] shared phobos library should not depend on _Dmain
http://d.puremagic.com/issues/show_bug.cgi?id=10711 --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2013-08-14 23:07:10 PDT --- 2nd try at fixing this: https://github.com/D-Programming-Language/dmd/pull/2476 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10722] Regression (2.064 git-head): Cannot interpret struct at compile-time
http://d.puremagic.com/issues/show_bug.cgi?id=10722 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-08-15 03:10:06 PDT --- https://github.com/D-Programming-Language/dmd/pull/2477 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10782] dmd segfault with string mixin, CTFE, class, non-literal initializer
http://d.puremagic.com/issues/show_bug.cgi?id=10782 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-08-15 03:21:27 PDT --- https://github.com/D-Programming-Language/dmd/pull/2478 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6210] Associative array with array key often cannot be equated.
http://d.puremagic.com/issues/show_bug.cgi?id=6210 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords|wrong-code |pull --- Comment #4 from hst...@quickfur.ath.cx 2013-08-15 07:54:52 PDT --- https://github.com/D-Programming-Language/dmd/pull/2479 https://github.com/D-Programming-Language/druntime/pull/573 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6210] Associative array with array key often cannot be equated.
http://d.puremagic.com/issues/show_bug.cgi?id=6210 --- Comment #5 from github-bugzi...@puremagic.com 2013-08-15 09:31:29 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/b8b4726a5e9d4781c3822a483abb66e8952323a8 Subsidiary fix for issue 6210. Add builtin typeinfo for const(char)[] so that it will use the same hash function as char[] and string. https://github.com/D-Programming-Language/druntime/commit/8aa3ebf8715fc6c49bedd2c0c18b92e6ed46b045 Merge pull request #573 from quickfur/issue6210 Subsidiary fix for issue 6210. --- Comment #6 from github-bugzi...@puremagic.com 2013-08-15 09:31:31 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3e811df8a9d1839282254d403fb9129f162fbe6f Merge pull request #2479 from quickfur/issue6210 Fix issue 6210 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6210] Associative array with array key often cannot be equated.
http://d.puremagic.com/issues/show_bug.cgi?id=6210 --- Comment #5 from github-bugzi...@puremagic.com 2013-08-15 09:31:29 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/b8b4726a5e9d4781c3822a483abb66e8952323a8 Subsidiary fix for issue 6210. Add builtin typeinfo for const(char)[] so that it will use the same hash function as char[] and string. https://github.com/D-Programming-Language/druntime/commit/8aa3ebf8715fc6c49bedd2c0c18b92e6ed46b045 Merge pull request #573 from quickfur/issue6210 Subsidiary fix for issue 6210. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6210] Associative array with array key often cannot be equated.
http://d.puremagic.com/issues/show_bug.cgi?id=6210 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from hst...@quickfur.ath.cx 2013-08-15 09:48:41 PDT --- Verified fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4410] AA has inconsistent and unreasonable requirements for iterating over reference-type index
http://d.puremagic.com/issues/show_bug.cgi?id=4410 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #4 from hst...@quickfur.ath.cx 2013-08-15 09:56:29 PDT --- AA keys only need to be immutable in the parts that are relevant to the hash function. For example, if a class object's toHash method simply casts 'this' to an integer value, then it doesn't matter what you change in the class, the AA will still work. Similarly, if a class object's toHash method computes a hash only on members x, y, z, then it's OK to change member variable w without breaking the AA. The only time you actually require immutability in AA keys is when you use the default hash function that computes a hash over the binary representation of the entire key. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4475] Improving the compiler 'in' associative array can return just a bool
http://d.puremagic.com/issues/show_bug.cgi?id=4475 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #9 from hst...@quickfur.ath.cx 2013-08-15 10:06:29 PDT --- (In reply to comment #8) [...] aa[a] = new C(); auto c = a in aa; aa[b] = new C(); // Using c here is undefined as an element was added to aa This can't happen if in returns a bool. Actually, that is not undefined. AA's are designed such that inserting new elements does not invalidate pointers to existing elements. In D, because we have a GC, even if you *delete* elements from AA's, pointers returned by 'in' continue to be valid. This holds even in the event of a rehash, because the pointer points to data in a Slot, and add/remove/rehash only shuffle pointers in the Slot, it doesn't move the Slot around in memory. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7503] ICE(cgcs.c) File[string] associative array
http://d.puremagic.com/issues/show_bug.cgi?id=7503 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords|ice |wrong-code --- Comment #2 from hst...@quickfur.ath.cx 2013-08-15 10:16:10 PDT --- Checked on git HEAD: the ICE no longer happens, but now a runtime exception is thrown: object.Exception@std/stdio.d(1442): Enforcement failed Looks like some kind of bad interaction with AA's and struct dtors. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10823] New: Aligned malloc functions for C heap
http://d.puremagic.com/issues/show_bug.cgi?id=10823 Summary: Aligned malloc functions for C heap Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2013-08-15 10:35:18 PDT --- In some low-level D programs you allocate memory from the C heap, so I suggest to add to Phobos three simple functions similar to the C standard functions that allocate and free memory aligned to the given number of bytes: void* alignedMalloc(in size_t size, in size_t alignment) nothrow; void* alignedCalloc(in size_t num, in size_t size, in size_t alignment) nothrow; void alignedFree(void* ptr) nothrow; The alignedFree doesn't need the alignment value because the allocating function write such value at the start of the memory chunk, just before where the given pointer points. An alternative safer API for alignedCalloc is, this, that turns it into a template: T* alignedCalloc(T)(in size_t num, in size_t alignment) nothrow; Such functions are meant to be used mostly for arrays in SIMD code, that needs data aligned to 16 bytes (SSE 3), 32 bytes (AVX), 64 bytes (Intel MIC), or more. They avoid the D programmer to write such functions over and over in D projects, that can also contain bugs. A standard library is meant to contain similar small functions that are sometimes useful. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10711] shared phobos library should not depend on _Dmain
http://d.puremagic.com/issues/show_bug.cgi?id=10711 --- Comment #5 from github-bugzi...@puremagic.com 2013-08-15 10:30:25 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0082669292b0a4e535420ea9aabcd57fd7844923 fix Issue 10711 - shared phobos library should not depend on _Dmain https://github.com/D-Programming-Language/dmd/commit/ab3a4030977d369b33f4d42b6964a134c7a800b5 Merge pull request #2476 from WalterBright/fix10711 fix Issue 10711 - shared phobos library should not depend on _Dmain -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10711] shared phobos library should not depend on _Dmain
http://d.puremagic.com/issues/show_bug.cgi?id=10711 Walter Bright bugzi...@digitalmars.com 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 4475] Improving the compiler 'in' associative array can return just a bool
http://d.puremagic.com/issues/show_bug.cgi?id=4475
--- Comment #10 from bearophile_h...@eml.cc 2013-08-15 10:49:03 PDT ---
(In reply to comment #9)
Actually, that is not undefined. AA's are designed such that inserting new
elements does not invalidate pointers to existing elements.
I didn't know this. Is this stated somewhere in the D specs?
This holds even in the event of a rehash,
Associative arrays have to grow when you keep adding key-value pairs, I presume
this is done allocating a new larger hash (probably 2 or 4 times larger), and
copying data in it. In such situation aren't the pointers to the items becoming
invalid? Even if the doubling is done with a realloc, it can sometimes not be
able to reallocate in place.
To test my theory I have written a small test program:
void main() {
enum size_t N = 1_000_000;
bool[immutable uint] aa;
auto pointers = new void*[N];
foreach (immutable uint i; 0 .. N) {
aa[i] = true;
pointers[i] = i in aa;
}
foreach (immutable uint i; 0 .. N)
assert(pointers[i] == (i in aa));
}
It gives no errors, so I am not understanding something. But are D specs
asserting this program will work in all D implementations?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10723] std.stdio.File.byLine causes segfault when compiling with -O
http://d.puremagic.com/issues/show_bug.cgi?id=10723
--- Comment #3 from Maxim Fomin ma...@maxim-fomin.ru 2013-08-15 10:53:46 PDT
---
Reduced:
struct File
{
private struct Impl
{
uint refs = uint.max / 2;
}
private Impl* _p;
private string _name;
this(string name, in char[] stdioOpenmode = rb)
{
_p = new Impl();
_p.refs = 1;
throw new Exception(name);
}
~this() {
assert(_p.refs);
--_p.refs;
_p = null;
}
int byLine() {
return 0;
}
}
void main() {
try {
int f = File(It's OK).byLine();
} catch(Exception e) { }
}
Interesting is that if _name member or in char[] stdioOpenmode = rb are
removed, the program runs fine.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10824] Unsupported regexp(?) error during run time
http://d.puremagic.com/issues/show_bug.cgi?id=10824 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@erdani.com AssignedTo|nob...@puremagic.com|dmitry.o...@gmail.com Severity|normal |blocker -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10781] ctRegex! throws a huge error
http://d.puremagic.com/issues/show_bug.cgi?id=10781 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@erdani.com AssignedTo|nob...@puremagic.com|dmitry.o...@gmail.com Severity|normal |blocker -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10825] [2.064 git-head
http://d.puremagic.com/issues/show_bug.cgi?id=10825 Nick Sabalausky cbkbbej...@mailinator.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10825] New: [2.064 git-head
http://d.puremagic.com/issues/show_bug.cgi?id=10825 Summary: [2.064 git-head Product: D Version: unspecified Platform: All OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: cbkbbej...@mailinator.com --- Comment #0 from Nick Sabalausky cbkbbej...@mailinator.com 2013-08-15 11:27:16 PDT --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10824] New: Unsupported regexp(?) error during run time
http://d.puremagic.com/issues/show_bug.cgi?id=10824
Summary: Unsupported regexp(?) error during run time
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: maliyat...@gmail.com
--- Comment #0 from milvakili maliyat...@gmail.com 2013-08-15 11:26:08 PDT ---
void main(string argv[]) {
auto myRegex = regex(`(?test)`, i);
}
Compiles but throws the following run time error. I think this should be
handled during compile time.
std.regex.RegexException@/opt/compilers/dmd2/include/std/regex.d(1947): ':',
'=', '', 'P' or '!' expected after '(?'
Pattern with error: `(?` --HERE-- `test)`
Pattern with error: `(?` --HERE-- `test)`
/home/d677/f315(ref @trusted std.regex.Parser!(immutable(char)[]).Parser
std.regex.Parser!(immutable(char)[]).Parser.__ctor!(const(char)[]).__ctor(immutable(char)[],
const(char)[])+0x98) [0x469978]
/home/d677/f315(@safe std.regex.Regex!(char).Regex
std.regex.regexImpl!(immutable(char)[]).regexImpl(immutable(char)[],
const(char)[])+0x5a) [0x453bca]
/home/d677/f315(std.regex.Regex!(char).Regex
std.functional.memoize!(_D3std5regex18__T9regexImplTAyaZ9regexImplFNfAyaAxaZS3std5regex12__T5RegexTaZ5Regex,
8).memoize(immutable(char)[], const(char)[])+0xe5) [0x470a55]
/home/d677/f315(@trusted std.regex.Regex!(char).Regex
std.regex.regex!(immutable(char)[]).regex(immutable(char)[],
const(char)[])+0x41) [0x453b59]
/home/d677/f315(_Dmain+0x39) [0x4537f9]
/home/d677/f315(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).void runMain()+0x18) [0x47bb4c]
/home/d677/f315(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).void tryExec(scope void delegate())+0x2a) [0x47b67e]
/home/d677/f315(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).void runAll()+0x40) [0x47bb9c]
/home/d677/f315(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).void tryExec(scope void delegate())+0x2a) [0x47b67e]
/home/d677/f315(_d_run_main+0x1ae) [0x47b63a]
/home/d677/f315(main+0x17) [0x47b487]
/usr/lib/libc.so.6(__libc_start_main+0xf5) [0x40967a15]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10801] std.regex: support for lookbehind in ctRegex
http://d.puremagic.com/issues/show_bug.cgi?id=10801 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@erdani.com AssignedTo|nob...@puremagic.com|dmitry.o...@gmail.com Severity|normal |blocker -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10826] New: Should the D GC allocate double4[] aligned to 32 bytes?
http://d.puremagic.com/issues/show_bug.cgi?id=10826 Summary: Should the D GC allocate double4[] aligned to 32 bytes? Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2013-08-15 11:33:49 PDT --- Currently the D GC allocates arrays aligned to 16 bytes fit to be used in XMM registers: auto a1 = new double2[128]; But I think the D GC should also return this a2 aligned to 32 bytes, as needed for efficiency for code that uses YMM registers, that are 256 bits long: auto a2 = new double4[64]; Eventually the D GC should return this a3 aligned to 64 bytes for efficiency of code that uses ZMM registers (Intel Xeon Phi), that are 512 bits long: auto a3 = new double8[32]; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10824] Unsupported regexp(?) error during run time
http://d.puremagic.com/issues/show_bug.cgi?id=10824
Dmitry Olshansky dmitry.o...@gmail.com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||INVALID
--- Comment #1 from Dmitry Olshansky dmitry.o...@gmail.com 2013-08-15
11:41:33 PDT ---
(In reply to comment #0)
void main(string argv[]) {
auto myRegex = regex(`(?test)`, i);
}
Compiles but throws the following run time error. I think this should be
handled during compile time.
It can't as auto myRegex is a run-time varaible and the expression on the right
may as well depend on external variables. See e.g.
auto myRegex = regex(argv[1], i);
How would that be handled at compile time?
But you can have your checking (and parsing btw) done at C-T using static:
static myRegex = regex(`(?test)`, i);
In the above myRegex will be precompiled at CTFE. No spedcial native code
generated unlike ctRegex, but no parsing at runtime. If need be you can create
static arrays of regex patterns at CTFE and later on assign them to local auto
variables.
So I'm marking this as resolved-invalid as there is nothing that can be done to
make original do CTFE (at the language level), and there is an easy solution
that is explicit and works.
std.regex.RegexException@/opt/compilers/dmd2/include/std/regex.d(1947): ':',
'=', '', 'P' or '!' expected after '(?'
Pattern with error: `(?` --HERE-- `test)`
Pattern with error: `(?` --HERE-- `test)`
/home/d677/f315(ref @trusted std.regex.Parser!(immutable(char)[]).Parser
std.regex.Parser!(immutable(char)[]).Parser.__ctor!(const(char)[]).__ctor(immutable(char)[],
const(char)[])+0x98) [0x469978]
/home/d677/f315(@safe std.regex.Regex!(char).Regex
std.regex.regexImpl!(immutable(char)[]).regexImpl(immutable(char)[],
const(char)[])+0x5a) [0x453bca]
/home/d677/f315(std.regex.Regex!(char).Regex
std.functional.memoize!(_D3std5regex18__T9regexImplTAyaZ9regexImplFNfAyaAxaZS3std5regex12__T5RegexTaZ5Regex,
8).memoize(immutable(char)[], const(char)[])+0xe5) [0x470a55]
/home/d677/f315(@trusted std.regex.Regex!(char).Regex
std.regex.regex!(immutable(char)[]).regex(immutable(char)[],
const(char)[])+0x41) [0x453b59]
/home/d677/f315(_Dmain+0x39) [0x4537f9]
/home/d677/f315(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).void runMain()+0x18) [0x47bb4c]
/home/d677/f315(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).void tryExec(scope void delegate())+0x2a) [0x47b67e]
/home/d677/f315(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).void runAll()+0x40) [0x47bb9c]
/home/d677/f315(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).void tryExec(scope void delegate())+0x2a) [0x47b67e]
/home/d677/f315(_d_run_main+0x1ae) [0x47b63a]
/home/d677/f315(main+0x17) [0x47b487]
/usr/lib/libc.so.6(__libc_start_main+0xf5) [0x40967a15]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4475] Improving the compiler 'in' associative array can return just a bool
http://d.puremagic.com/issues/show_bug.cgi?id=4475 --- Comment #11 from hst...@quickfur.ath.cx 2013-08-15 12:03:49 PDT --- (In reply to comment #10) [...] Associative arrays have to grow when you keep adding key-value pairs, I presume this is done allocating a new larger hash (probably 2 or 4 times larger), and copying data in it. In such situation aren't the pointers to the items becoming invalid? Even if the doubling is done with a realloc, it can sometimes not be able to reallocate in place. The reason it works, is because the hash table itself doesn't contain the actual key/value pairs; it just contains pointers to linked-lists of these key/value pairs. So the hash table can be modified however you like, but the key/value pairs stays in the same memory address. This would work even if we used something other than linked-lists for the key/value pairs, e.g., trees, because the key/value pairs would just have some pointers to neighbouring nodes, and during AA rehash (or add/delete) all that happens is that some of these pointers get reassigned, but the node itself (containing the key/value pair) remains in the same memory address. This kind of implementation avoids copying/moving of keys and values, so I'd expect any good AA implementation to do something similar. I'm pretty sure that it's generally expected that AA implementations should obey the principle that iterators (i.e. pointers to key/value) are not invalidated by add/delete, otherwise it would greatly reduce the usefulness of AA's. I'm not too sure about this also holding for rehash, but the current AA implementation does indeed preserve references across rehash as well (though it does break iteration order if you trigger a rehash in the middle of iterating over the AA -- but you won't get invalid pointers out of it). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10723] std.stdio.File.byLine causes segfault when compiling with -O
http://d.puremagic.com/issues/show_bug.cgi?id=10723 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added Keywords||accepts-invalid --- Comment #4 from Maxim Fomin ma...@maxim-fomin.ru 2013-08-15 12:17:26 PDT --- (In reply to comment #3) Interesting is that if _name member or in char[] stdioOpenmode = rb are removed, the program runs fine. This is actually a funny bug - in char[] stdioOpenmode = rb shouldn't compile in first place, this is accept-invalid. This erroneous default parameter as a result causes further problems with dehtables as offsets are wrong. https://github.com/D-Programming-Language/phobos/pull/1478 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9119] Forward range addition to associative arrays.
http://d.puremagic.com/issues/show_bug.cgi?id=9119 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull CC||hst...@quickfur.ath.cx --- Comment #2 from hst...@quickfur.ath.cx 2013-08-15 12:23:05 PDT --- https://github.com/D-Programming-Language/druntime/pull/574 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10723] std.stdio.File.byLine causes segfault when compiling with -O
http://d.puremagic.com/issues/show_bug.cgi?id=10723 --- Comment #5 from Maxim Fomin ma...@maxim-fomin.ru 2013-08-15 12:20:37 PDT --- Separate issue for dmd bug http://d.puremagic.com/issues/show_bug.cgi?id=10723 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10827] New: Erroneous default string argument for a char[] type
http://d.puremagic.com/issues/show_bug.cgi?id=10827
Summary: Erroneous default string argument for a char[] type
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ma...@maxim-fomin.ru
--- Comment #0 from Maxim Fomin ma...@maxim-fomin.ru 2013-08-15 12:20:10 PDT
---
Originally detected in issue 10723
struct File
{
private struct Impl
{
uint refs = uint.max / 2;
}
private Impl* _p;
private string _name;
this(string name, in char[] stdioOpenmode = )
{
_p = new Impl();
_p.refs = 1;
throw new Exception(name);
}
~this() {
assert(_p.refs);
--_p.refs;
_p = null;
}
int byLine() {
return 0;
}
}
void main() {
try {
int f = File(It's OK).byLine();
} catch(Exception e) { }
}
Code in char[] stdioOpenmode = shouldn't be compiled.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10723] std.stdio.File.byLine causes segfault when compiling with -O
http://d.puremagic.com/issues/show_bug.cgi?id=10723 --- Comment #6 from hst...@quickfur.ath.cx 2013-08-15 12:27:18 PDT --- (In reply to comment #4) (In reply to comment #3) Interesting is that if _name member or in char[] stdioOpenmode = rb are removed, the program runs fine. This is actually a funny bug - in char[] stdioOpenmode = rb shouldn't compile in first place, this is accept-invalid. This erroneous default parameter as a result causes further problems with dehtables as offsets are wrong. https://github.com/D-Programming-Language/phobos/pull/1478 Why is this invalid? I thought 'in char[]' just means const(char[]), which immutable(char)[] should be implicitly convertible to. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9119] Forward range addition to associative arrays.
http://d.puremagic.com/issues/show_bug.cgi?id=9119
--- Comment #3 from hst...@quickfur.ath.cx 2013-08-15 12:33:54 PDT ---
Using the code in the pull request, this code works:
import std.algorithm;
import std.conv;
import std.stdio: writeln;
void main () {
int[string] aa;
aa[a] = 1;
aa[b] = 2;
aa[c] = 3;
writeln(aa.byPair
.map!((a) = key= ~ a.key ~ value= ~ to!string(a.value))
.joiner(\n)
);
}
The output is:
key=a value=1
key=b value=2
key=c value=3
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10723] std.stdio.File.byLine causes segfault when compiling with -O
http://d.puremagic.com/issues/show_bug.cgi?id=10723 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added Keywords|accepts-invalid, pull | --- Comment #7 from Maxim Fomin ma...@maxim-fomin.ru 2013-08-15 12:49:25 PDT --- (In reply to comment #6) (In reply to comment #4) (In reply to comment #3) Interesting is that if _name member or in char[] stdioOpenmode = rb are removed, the program runs fine. This is actually a funny bug - in char[] stdioOpenmode = rb shouldn't compile in first place, this is accept-invalid. This erroneous default parameter as a result causes further problems with dehtables as offsets are wrong. https://github.com/D-Programming-Language/phobos/pull/1478 Why is this invalid? I thought 'in char[]' just means const(char[]), which immutable(char)[] should be implicitly convertible to. Yes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10827] Erroneous default string argument for a char[] type
http://d.puremagic.com/issues/show_bug.cgi?id=10827 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4475] Improving the compiler 'in' associative array can return just a bool
http://d.puremagic.com/issues/show_bug.cgi?id=4475 --- Comment #12 from bearophile_h...@eml.cc 2013-08-15 12:52:19 PDT --- (In reply to comment #11) the hash table itself doesn't contain the actual key/value pairs; it just contains pointers to linked-lists of these key/value pairs. So the hash table can be modified however you like, but the key/value pairs stays in the same memory address. I see. But that's just an implementation detail (you could design an AA that keeps small keys-value pairs in an array, plus a pointer to a chain for the collisions, this is how I have created associative arrays in C), D specs can't assert that implementation, so D code that relies on that implementation detail goes into the realm of undefined behavour. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10161] std.datetime unittest failure Libya Standard Time
http://d.puremagic.com/issues/show_bug.cgi?id=10161 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #2 from monarchdo...@gmail.com 2013-08-15 12:50:42 PDT --- I used to hit this on my win8 too. I don't have win8 anymore, so I can't verify if this is fixed or not. I *believe* Jonathan fixed it. Could somebody confirm (or deny) that this was fixed? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10828] New: datetime toString functions should accept sink
http://d.puremagic.com/issues/show_bug.cgi?id=10828 Summary: datetime toString functions should accept sink Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2013-08-15 12:59:01 PDT --- Basically, all datetime functions' toString signature are: string toString(); There should be an overload which accepts a sink (eg:) const void toString(scope void delegate(const(char)[]) sink); Without this, code such as: writeln(currentTime) Will needlessly allocate a string. This is an issue for this user: http://forum.dlang.org/thread/ofelyiymbyywethtf...@forum.dlang.org#post-ypgppdursxtwljhkjoed:40forum.dlang.org Who wants to log the time at which destruction happens. This leads to a: core.exception.InvalidMemoryOperationError Due to an allocation during a collect. Implementation should be trivial*, since the implementation of toString is basically return format(, args). So this can easily be changed to: formattedWrite(sink, , args) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10161] std.datetime unittest failure Libya Standard Time
http://d.puremagic.com/issues/show_bug.cgi?id=10161 --- Comment #3 from Dmitry Olshansky dmitry.o...@gmail.com 2013-08-15 12:56:25 PDT --- (In reply to comment #2) I used to hit this on my win8 too. I don't have win8 anymore, so I can't verify if this is fixed or not. I *believe* Jonathan fixed it. Could somebody confirm (or deny) that this was fixed? Which commit ? ;) Still fails for me. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10161] std.datetime unittest failure Libya Standard Time
http://d.puremagic.com/issues/show_bug.cgi?id=10161 --- Comment #5 from monarchdo...@gmail.com 2013-08-15 13:04:57 PDT --- (In reply to comment #3) (In reply to comment #2) I used to hit this on my win8 too. I don't have win8 anymore, so I can't verify if this is fixed or not. I *believe* Jonathan fixed it. Could somebody confirm (or deny) that this was fixed? Which commit ? ;) Still fails for me. Nevermind, it looks like I am thinking of this: https://github.com/D-Programming-Language/phobos/pull/1411/files#L1R30444 Which seems to not yet be merged. I think we should get it reviewed and pulled. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10161] std.datetime unittest failure Libya Standard Time
http://d.puremagic.com/issues/show_bug.cgi?id=10161 --- Comment #4 from Rainer Schuetze r.sagita...@gmx.de 2013-08-15 13:01:28 PDT --- I have guessed some names as part of running unittests on win64: https://github.com/D-Programming-Language/phobos/pull/1411 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10829] New: -inline produces wrong code
http://d.puremagic.com/issues/show_bug.cgi?id=10829
Summary: -inline produces wrong code
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: temta...@gmail.com
--- Comment #0 from Temtaime temta...@gmail.com 2013-08-15 13:34:12 PDT ---
I have a big project, so i cannot figure test-case now. I'll investigate in it
a little later. Minimized piece of code that demonstrates the problem.
static void bringToTop(GUIElement[] arr) {
if(arr.length 2)
return;
auto p = arr[0];
auto c = arr[1];
writefln(`c == %s`, cast(int)cast(void *)c);
p._childs = c ~ p._childs.filter!(a = (writefln(`in lambda c == %s`,
cast(int)cast(void *)c), a != c)).array;
}
GUIElement is a class. GUIElement._childs is an array of GUIElement.
Output with -inline:
c == 7982336
in lambda c == 0
Optput without -inline:
c == 3751104
in lambda c == 3751104
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10830] New: DMD generates two identical version of templated functions
http://d.puremagic.com/issues/show_bug.cgi?id=10830
Summary: DMD generates two identical version of templated
functions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: temta...@gmail.com
--- Comment #0 from Temtaime temta...@gmail.com 2013-08-15 14:50:12 PDT ---
Lets look at that simple code.
void foo(int line = __LINE__)() {
debug
writeln(`hello, world `, line);
else
writeln(`hello, world`);
}
void main() {
foo();
foo();
}
So we have in the binary two identical versions of code if we compile it with
-release -O -inline.
If the function is big and have been called from many places, then size of
binary can increases extremely.
I think it's need to improve frontend a little: check if template parametes not
used across the function and then drops it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2278] Guarantee alignment of stack-allocated variables on x86
http://d.puremagic.com/issues/show_bug.cgi?id=2278
Temtaime temta...@gmail.com changed:
What|Removed |Added
CC||temta...@gmail.com
--- Comment #11 from Temtaime temta...@gmail.com 2013-08-15 15:47:59 PDT ---
BUMP.
2.63.2 regression ?
import core.stdc.stdio: printf;
align(16) struct Foo { ubyte u; }
// struct Foo { ubyte u; } // try this
void main() {
Foo f1;
ubyte[3] b1;
Foo f2;
ubyte[5] b2;
Foo f3;
ubyte[7] b3;
short s1;
Foo f4;
printf(%u\n, cast(size_t)f1 % 16);
printf(%u\n, cast(size_t)f2 % 16);
printf(%u\n, cast(size_t)f3 % 16);
printf(%u\n, cast(size_t)f4 % 16);
}
Output:
8
8
8
8
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10826] Should the D GC allocate double4[] aligned to 32 bytes?
http://d.puremagic.com/issues/show_bug.cgi?id=10826 Manu turkey...@gmail.com changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #1 from Manu turkey...@gmail.com 2013-08-15 20:48:42 PDT --- Yes, double4 should intrinsically be align(32), just like float4/double2 is intrinsically align(16). Likewise, align(64) for ZMM regs. The GC should respect the explicit alignment of any type. If it doesn't, then that is another bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10826] Should the D GC allocate double4[] aligned to 32 bytes?
http://d.puremagic.com/issues/show_bug.cgi?id=10826 --- Comment #2 from Manu turkey...@gmail.com 2013-08-15 20:51:55 PDT --- For clarity, as a simple compiler rule, all __vector() types should be intrinsically aligned to their .sizeof. This is correct on all architectures I know of. There is the occasional architecture that might not mind a smaller alignment, but I think it's still valuable to enforce the alignment on those (rare) platforms for portability (structure consistency across platforms), especially since those platforms are often tested less thoroughly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
