[Issue 12242] conflict error with public imports
https://d.puremagic.com/issues/show_bug.cgi?id=12242 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2014-03-23 01:28:26 PDT --- This is not a compiler bug. It has nothing to do with 314. The problem is that 'strip' is defined in both std.string and std.algorithm. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12440] Implement whole-program analysis
https://d.puremagic.com/issues/show_bug.cgi?id=12440 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com 2014-03-23 10:28:55 EET --- Can we have rdmd specify this flag by default, since it is passing all included files to the compiler? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12242] conflict error with public imports
https://d.puremagic.com/issues/show_bug.cgi?id=12242
--- Comment #5 from Vladimir Panteleev thecybersha...@gmail.com 2014-03-23
10:33:53 EET ---
This is a compiler bug because this program doesn't compile (as is expected):
/// test.d //
import std.algorithm;
void main()
{
af .strip;
}
/
And this program compiles (as it should):
/// test.d //
import std.algorithm;
import std.string;
void main()
{
af .strip;
}
/
Note that the above program differs from OP's only in how imports are
funneled.
Therefore, there should be no conflict, because out of std.algorithm.strip and
std.string.strip, only one will work with those parameters.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12432] Diagnostic on argument count mismatch for ranges and opApply should improve
https://d.puremagic.com/issues/show_bug.cgi?id=12432 --- Comment #2 from github-bugzi...@puremagic.com 2014-03-23 01:55:57 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a38a23830977a42f9b36a51d7e4e7a6e9b917ad1 Fix Issue 12432 - Implement better diagnostics for argument count mismatch in range and opApply contexts. https://github.com/D-Programming-Language/dmd/commit/86d59a72df020fedc6e3bc87a885fa969121ea3e Merge pull request #3396 from AndrejMitrovic/Fix12432 Issue 12432 - Better diagnostics for argument count mismatch in range and opApply -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12442] New: inefficient code with scope(exit)
https://d.puremagic.com/issues/show_bug.cgi?id=12442
Summary: inefficient code with scope(exit)
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: performance
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze r.sagita...@gmx.de 2014-03-23 01:55:50
PDT ---
Usage of scope(exit) comes with a significant performance cost, even if the
executed code is nothrow:
/
uint fun() nothrow;
__gshared int recurse;
uint wrapper_scopeexit()
{
recurse++;
scope(exit) recurse--;
return fun();
}
uint wrapper_linear()
{
recurse++;
uint rc = fun();
recurse--;
return rc;
}
//
This is the assembly for Win64 with -O:
_D4test17wrapper_scopeexitFZk:
: 55 pushrbp
0001: 48 8B EC mov rbp,rsp
0004: 48 83 EC 18sub rsp,18h
0008: 53 pushrbx
0009: 56 pushrsi
000A: 57 pushrdi
000B: 41 54 pushr12
000D: 41 55 pushr13
000F: 41 56 pushr14
0011: 41 57 pushr15
0013: FF 05 00 00 00 00 inc dword ptr [_D4test7recursei]
0019: 48 83 EC 20sub rsp,20h
001D: E8 00 00 00 00 call_D4test3funFNbZk
0022: 48 83 C4 20add rsp,20h
0026: 48 89 45 F8mov qword ptr [rbp-8],rax
002A: 48 83 EC 08sub rsp,8
002E: E8 28 00 00 00 call005B
0033: 48 83 C4 08add rsp,8
0037: 48 8B 45 F8mov rax,qword ptr [rbp-8]
003B: 41 5F pop r15
003D: 41 5E pop r14
003F: 41 5D pop r13
0041: 41 5C pop r12
0043: 5F pop rdi
0044: 5E pop rsi
0045: 5B pop rbx
0046: 48 8D 65 00lea rsp,[rbp]
004A: 5D pop rbp
004B: C3 ret
004C: 48 83 EC 08sub rsp,8
0050: E8 06 00 00 00 call005B
0055: 48 83 C4 08add rsp,8
0059: EB 07 jmp 0062
005B: FF 0D 00 00 00 00 dec dword ptr [_D4test7recursei]
0061: C3 ret
0062: 41 5F pop r15
0064: 41 5E pop r14
0066: 41 5D pop r13
0068: 41 5C pop r12
006A: 5F pop rdi
006B: 5E pop rsi
006C: 5B pop rbx
006D: 48 8D 65 00lea rsp,[rbp]
0071: 5D pop rbp
0072: C3 ret
_D4test14wrapper_linearFZk:
: 55 pushrbp
0001: 48 8B EC mov rbp,rsp
0004: FF 05 00 00 00 00 inc dword ptr [_D4test7recursei]
000A: 48 83 EC 20sub rsp,20h
000E: E8 00 00 00 00 call_D4test3funFNbZk
0013: 48 83 C4 20add rsp,20h
0017: FF 0D 00 00 00 00 dec dword ptr [_D4test7recursei]
001D: 5D pop rbp
001E: C3 ret
For Win32, it is slightly worse because the exception frames are still set up:
_D4test17wrapper_scopeexitFZkcomdat
assumeCS:_D4test17wrapper_scopeexitFZk
L0:pushEBP
movEBP,ESP
movEDX,FS:__except_list
push0h
pushoffset _D4test17wrapper_scopeexitFZk[07Ch]
pushEDX
movFS:__except_list,ESP
subESP,8
pushEBX
pushESI
pushEDI
incdword ptr _D4test7recursei
movdword ptr -4[EBP],0
callnear ptr _D4test3funFNbZk
movdword ptr -4[EBP],0h
pushEAX
callnear ptr L5A
popEAX
movECX,-0Ch[EBP]
movFS:__except_list,ECX
popEDI
popESI
popEBX
mov
[Issue 12442] inefficient code with scope(exit)
https://d.puremagic.com/issues/show_bug.cgi?id=12442
--- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2014-03-23 02:01:32
PDT ---
The same happens with RAII:
struct SCount
{
this(bool) nothrow { recurse++; }
~this() nothrow { recurse--; }
}
uint wrapper_raii() nothrow
{
SCount sc = SCount(true);
return fun();
}
produces almost the same code as scope(exit).
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12440] Implement whole-program analysis
https://d.puremagic.com/issues/show_bug.cgi?id=12440 --- Comment #3 from bearophile_h...@eml.cc 2014-03-23 02:22:51 PDT --- (In reply to comment #2) Can we have rdmd specify this flag by default, since it is passing all included files to the compiler? A whole-program class hierarchy analysis is probably fast, but a complete virtual methods analysis could take a bit of time, so if you want a fast compilation you should be able to tall rdmd to not perform it. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12440] Implement whole-program analysis
https://d.puremagic.com/issues/show_bug.cgi?id=12440 Marco Leise marco.le...@gmx.de changed: What|Removed |Added CC||marco.le...@gmx.de --- Comment #4 from Marco Leise marco.le...@gmx.de 2014-03-23 02:25:35 PDT --- (In reply to comment #2) Can we have rdmd specify this flag by default, since it is passing all included files to the compiler? No, because it breaks all applications that use plugins to extend the class hierarchy. It must be a well-informed decision. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12440] Implement whole-program analysis
https://d.puremagic.com/issues/show_bug.cgi?id=12440 --- Comment #5 from Vladimir Panteleev thecybersha...@gmail.com 2014-03-23 11:28:43 EET --- With the current state of D shared libraries, how many of those do we have anyway? If a change improves performance for 99% of code and breaks 1%, I think that's a worthwhile change. We have a precedent (the -allinst switch and related changes). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12316] GIT HEAD: AA.get broken for Object VAL types
https://d.puremagic.com/issues/show_bug.cgi?id=12316 --- Comment #3 from github-bugzi...@puremagic.com 2014-03-23 02:34:47 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/64dc5d0f286fb40d09b06984419333b8db2f4a2d fix Issue 12316 - AA.get broken for Object VAL types More better fix for the issue 7757. https://github.com/D-Programming-Language/dmd/commit/7d19a26a579b8c700d8bb59a1e9c63a6d56aad53 Merge pull request #3369 from 9rnsr/fix12316 [REG2.066a] Issue 12316 - AA.get broken for Object VAL types -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11461] `Error`s are not thrown as `pure nothrow` functions are optimized out with -O -release
https://d.puremagic.com/issues/show_bug.cgi?id=11461 --- Comment #14 from Rainer Schuetze r.sagita...@gmx.de 2014-03-23 02:32:33 PDT --- I agree, it seems the better workaround. Clever compilers might notice that the passed parameter introduces no sideeffects and might infer strong purity, though. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12440] Implement whole-program analysis
https://d.puremagic.com/issues/show_bug.cgi?id=12440 --- Comment #6 from Marco Leise marco.le...@gmx.de 2014-03-23 02:48:39 PDT --- (In reply to comment #5) With the current state of D shared libraries, how many of those do we have anyway? Close to none I guess. If a change improves performance for 99% of code and breaks 1%, I think that's a worthwhile change. The argument being? The state of shared libraries will continue to improve steadily as it did in the past. -wholeprogram (as described above) will cause issues once D gets there and the 1% deliberate silent breakage increases. At the minimum there would have to be a runtime error on loading plugins into a program compiled with -wholeprogram. And to pick up a suggestion on the forum by Ola, there could be a mechanism in place to tell the compiler which classes you need excluded from devirtualization, so you can use -wholeprogram together with plugins. We have a precedent (the -allinst switch and related changes). I didn't follow the discussion around -allinst so I cannot comment on that. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12432] Diagnostic on argument count mismatch for ranges and opApply should improve
https://d.puremagic.com/issues/show_bug.cgi?id=12432 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12382] `opDollar` can't be used at CT
https://d.puremagic.com/issues/show_bug.cgi?id=12382 --- Comment #4 from github-bugzi...@puremagic.com 2014-03-23 03:07:19 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/4c97247132864c2dea65f6743392261c90ec8ac0 fix Issue 12382 - `opDollar` can't be used at CT Front-end should handle opDollar side-effect carefully, because CTFE engine cannot interpret `(auto __dollar = obj.opDollar(), obj).opIndex(__dollar)` without CTFE stack. https://github.com/D-Programming-Language/dmd/commit/efe0e45fecfa2b324ae382e77e6456a419abc657 Merge pull request #3385 from 9rnsr/fix12382 Issue 12382 - `opDollar` can't be used at CT -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12443] New: Allow passing DLLs directly to DMD to avoid the need for creating import libraries
https://d.puremagic.com/issues/show_bug.cgi?id=12443 Summary: Allow passing DLLs directly to DMD to avoid the need for creating import libraries Product: D Version: D2 Platform: All OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-03-23 03:10:12 PDT --- Comments from: https://github.com/D-Programming-Language/dmd/pull/3397#issuecomment-38364330 https://github.com/D-Programming-Language/dmd/pull/3397#issuecomment-38376746 W.r.t. Windows, I was thinking the other day that it would be great if we could pass DLLs to DMD directly instead of having to create an import library as a separate step. But neither implib nor coffimplib are open-source so I don't know how hard it would be to implement this in the compiler. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12441] DDoc should ignore interleaved non-doc comments
https://d.puremagic.com/issues/show_bug.cgi?id=12441 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-03-23 03:14:33 PDT --- I can't seem to recreate this from the test-case.(In reply to comment #0) /// Documentation comment // Non-documentation comment void foo(); I can't reproduce this, the test-case must be something else. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12443] Allow passing DLLs directly to DMD to avoid the need for creating import libraries
https://d.puremagic.com/issues/show_bug.cgi?id=12443 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com 2014-03-23 12:13:43 EET --- For the record, Delphi does away with import libraries completely and solves the DLL problem in the language. E.g.: function MessageBoxA(hWnd: HWND; lpText, lpCaption: PChar; uType: UINT): Integer; stdcall; external 'user32.dll'; So in theory D could have an extern(dll, user32.dll) attribute. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12443] Allow passing DLLs directly to DMD to avoid the need for creating import libraries
https://d.puremagic.com/issues/show_bug.cgi?id=12443
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-03-23
03:24:26 PDT ---
(In reply to comment #1)
For the record, Delphi does away with import libraries completely and solves
the DLL problem in the language. E.g.:
function MessageBoxA(hWnd: HWND; lpText, lpCaption: PChar; uType: UINT):
Integer; stdcall; external 'user32.dll';
So in theory D could have an extern(dll, user32.dll) attribute.
It would be a little complicated with platform-independent shared libraries.
For example:
-
version (Windows) extern(dll, user32.dll)
extern(C) void foo();
void main()
{
foo(); // would fail on Posix since the entire block becomes invisible
}
-
We currently cannot do the following:
-
version (Windows)
extern(C++):
else
extern(C):
void foo();
void main()
{
}
-
Unless this is fixed extern(dll, user32.dll) would only be usable for Windows
DLLs, or you'd likely have to duplicate code / resort to string mixins and
other unreadable hacks..
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11461] `Error`s are not thrown as `pure nothrow` functions are optimized out with -O -release
https://d.puremagic.com/issues/show_bug.cgi?id=11461 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Keywords||pull --- Comment #15 from Rainer Schuetze r.sagita...@gmx.de 2014-03-23 03:28:42 PDT --- https://github.com/D-Programming-Language/druntime/pull/753 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12378] Compiler accepts any syntactically-valid code inside double-nested map predicate
https://d.puremagic.com/issues/show_bug.cgi?id=12378 --- Comment #2 from github-bugzi...@puremagic.com 2014-03-23 03:41:20 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b8380bc668d62040c2f91c98ccd694ace46fd2aa fix Issue 12378 - Compiler accepts any syntactically-valid code inside double-nested map predicate https://github.com/D-Programming-Language/dmd/commit/4d3bbfb0639cc4f28272d816f795c0f12cd4f2e5 Merge pull request #3383 from 9rnsr/fix12378 Issue 12378 - Compiler accepts any syntactically-valid code inside double-nested map predicate -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11075] ICE(struct.c) after gagged error in struct field initializer
https://d.puremagic.com/issues/show_bug.cgi?id=11075 --- Comment #8 from github-bugzi...@puremagic.com 2014-03-23 03:41:11 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/fceb16bbf772b0130348394210dc6fdef95fdcf1 More better fix for issue 11075 to reproduce semantic3 errors in already failed template instance -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12443] Allow passing DLLs directly to DMD to avoid the need for creating import libraries
https://d.puremagic.com/issues/show_bug.cgi?id=12443 --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com 2014-03-23 12:44:20 EET --- It would be simpler if the project is already using some non-trivial build system. Allowing specifying it in the source code has the same advantage as pragma(lib): it allows using only rdmd to build the program. I think there is merit in both. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12443] Allow passing DLLs directly to DMD to avoid the need for creating import libraries
https://d.puremagic.com/issues/show_bug.cgi?id=12443
--- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-03-23
03:42:05 PDT ---
(In reply to comment #2)
-
version (Windows) extern(dll, user32.dll)
extern(C) void foo();
void main()
{
foo(); // would fail on Posix since the entire block becomes invisible
}
-
That wasn't a proper argument since the dll string name can be generated at
compile-time.
To provide a slightly better argument, let's say you have foo.dll,
foo_deb.dll on Windows, and foo.a, foo_deb.a on Posix. You'd end up
writing:
-
version (Windows)
{
debug
enum dll_name = foo.dll;
else
enum dll_name = foo_deb;
}
else
version (Posix)
{
debug
enum dll_name = foo.a;
else
enum dll_name = foo_deb.a;
}
extern(dll, dll_name)
void foo();
-
But then there might be issues where the shared library is named differently
based on the OS itself, some platform-specific naming conventions, x86 vs x64,
etc.. It would be simpler if you could just pass the shared library directly to
DMD.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12443] Allow passing DLLs directly to DMD to avoid the need for creating import libraries
https://d.puremagic.com/issues/show_bug.cgi?id=12443 --- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-03-23 03:47:16 PDT --- (In reply to comment #4) It would be simpler if the project is already using some non-trivial build system. Allowing specifying it in the source code has the same advantage as pragma(lib): it allows using only rdmd to build the program. Well, yeah, but you still can't provide strings at compile time via a compiler switch, maybe only through string imports. (In reply to comment #4) I think there is merit in both. Yes, agreed. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12444] New: std.array uninitializedArray minimallyInitializedArray missing APPENDABLE attribute / capacity info
https://d.puremagic.com/issues/show_bug.cgi?id=12444
Summary: std.array uninitializedArray
minimallyInitializedArray missing APPENDABLE attribute
/ capacity info
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: safety0ff.b...@gmail.com
--- Comment #0 from safety0ff.bugz safety0ff.b...@gmail.com 2014-03-23
03:48:59 PDT ---
import std.array;
import std.stdio;
import core.memory;
void main()
{
double[] a = uninitializedArray!(double[])(100);
a = a[0 .. 1];
assert(a.capacity == 0);
a.assumeSafeAppend();
assert(a.capacity != 0); // Error
double[] b = minimallyInitializedArray!(double[])(100);
b = b[0 .. 1];
assert(b.capacity == 0);
b.assumeSafeAppend();
assert(b.capacity != 0); // Error
double[] c = new double[100];
c = c[0 .. 1];
assert(c.capacity == 0);
c.assumeSafeAppend();
assert(c.capacity != 0); // OK!
auto dptr = cast(double*)GC.malloc(100 * double.sizeof, GC.BlkAttr.NO_SCAN
| GC.BlkAttr.APPENDABLE);
double[] d = dptr[0 .. 100];
d = d[0 .. 1];
assert(d.capacity == 0);
d.assumeSafeAppend();
assert(d.capacity != 0); // OK!
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9106] Rename std.random.randomShuffle as std.random.shuffle and small usage change
https://d.puremagic.com/issues/show_bug.cgi?id=9106 --- Comment #12 from Ivan Kazmenko ga...@mail.ru 2014-03-23 04:02:39 PDT --- (In reply to comment #9) (In reply to comment #8) So, for me, the problem reduced to whether randomCover could use a wholly different, better name. So, how is this function called in other languages? Without any knowledge of how it's addressed in other languages, I would have been inclined to call it permute. But I'll look around (you didn't find anything appropriate in your existing search of Python and C++?) No, I didn't see a similar function in other languages. The function itself seems a bit odd to me, even after I got an explanation of a possible use case (in this old thread: http://forum.dlang.org/thread/kuvhrfnrrbhzpyoir...@forum.dlang.org#post-kuvhrfnrrbhzpyoirqgt:40forum.dlang.org). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9106] Rename std.random.randomShuffle as std.random.shuffle and small usage change
https://d.puremagic.com/issues/show_bug.cgi?id=9106 --- Comment #13 from bearophile_h...@eml.cc 2014-03-23 04:09:19 PDT --- (In reply to comment #12) No, I didn't see a similar function in other languages. The function itself seems a bit odd to me, even after I got an explanation of a possible use case (in this old thread: http://forum.dlang.org/thread/kuvhrfnrrbhzpyoir...@forum.dlang.org#post-kuvhrfnrrbhzpyoirqgt:40forum.dlang.org). That thread also refers to this issue: http://d.puremagic.com/issues/show_bug.cgi?id=2898 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12403] [AA] Associative array `get` function rejects some cases
https://d.puremagic.com/issues/show_bug.cgi?id=12403 --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com 2014-03-23 16:38:05 EET --- I guess it's not related to issue 12316, because the pull that fixed it did not fix this issue. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9106] Rename std.random.randomShuffle as std.random.shuffle and small usage change
https://d.puremagic.com/issues/show_bug.cgi?id=9106 --- Comment #14 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2014-03-23 07:59:45 PDT --- (In reply to comment #12) No, I didn't see a similar function in other languages. The function itself seems a bit odd to me, even after I got an explanation of a possible use case (in this old thread: http://forum.dlang.org/thread/kuvhrfnrrbhzpyoir...@forum.dlang.org#post-kuvhrfnrrbhzpyoirqgt:40forum.dlang.org). The rationale that I can see for randomCover would be that it ought to provide a non-destructive (i.e. no in-place shuffling), non-allocating (i.e. no .dup-ing or .save-ing of the original range) way of getting a random permutation of the elements of the range provided as input. However, currently randomCover fails on the second of these in any case, because it contains and allocates an internal array of bools, _chosen. I think that to be honest we simply need to do research and identify a better algorithm than the one currently implemented. One such must exist. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9106] Rename std.random.randomShuffle as std.random.shuffle and small usage change
https://d.puremagic.com/issues/show_bug.cgi?id=9106 --- Comment #15 from Ivan Kazmenko ga...@mail.ru 2014-03-23 08:10:27 PDT --- (In reply to comment #14) The rationale that I can see for randomCover would be that it ought to provide a non-destructive (i.e. no in-place shuffling), non-allocating (i.e. no .dup-ing or .save-ing of the original range) way of getting a random permutation of the elements of the range provided as input. However, currently randomCover fails on the second of these in any case, because it contains and allocates an internal array of bools, _chosen. I think that to be honest we simply need to do research and identify a better algorithm than the one currently implemented. One such must exist. I don't think a no-allocation version would be possible at all. Consider having already covered N/2 elements out of N elements. There are Choose (N, N/2) possible ways to do so. To provide the next element, and then again and again, N/2 more times, we have to remember that exact state somehow. Hence we have to store at least log (Choose (N, N/2)) bits at that moment to distinguish between the states, which is of the order N/2. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12242] conflict error with public imports
https://d.puremagic.com/issues/show_bug.cgi?id=12242
--- Comment #6 from Kenji Hara k.hara...@gmail.com 2014-03-23 08:57:48 PDT ---
(In reply to comment #4)
This is not a compiler bug. It has nothing to do with 314.
The problem is that 'strip' is defined in both std.string and std.algorithm.
This is a compiler bug on cross-module overload set handling. It's not directly
related to issue 313 314.
test.d:
module test;
public:
import std.string;
import std.algorithm;
In test.d, 'strip' is a cross module overload set (CMOS) of 'std.string.strip'
and 'std.algorithm.strip'.
main.d:
import test;
import std.string;
void main(){ auto a= af .strip;}
In main.d, 'strip' is a CMOS of the CMOS in test.d and 'std.stding.strip'.
So, the newly created CMOS should be merged to the set [std.string.strip,
std.algorithm.strip]. But currently OverloadSet and template cannot be merged
into one OverloadSet object in ScopeDsymbol::search.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12445] New: std.bitmanip.read should have overloads specifying the count of bytes to read
https://d.puremagic.com/issues/show_bug.cgi?id=12445
Summary: std.bitmanip.read should have overloads specifying the
count of bytes to read
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-03-23
09:05:24 PDT ---
This seems to be a common occurrence in D code:
-
uint pop24bitsLE(R)(ref R input) if (isInputRange!R)
{
ubyte b0 = popByte(input);
ubyte b1 = popByte(input);
ubyte b2 = popByte(input);
return (b2 16) | (b1 8) | b0;
}
-
std.bitmanip comes close with:
-
import std.bitmanip;
uint u = range.read!(uint, Endian.littleEndian)();
-
But this will actually read 4 bytes instead of 3. I propose we add an overload
or two via:
-
// compile-time byte-count version
T read(T, Endian endianness = Endian.bigEndian, R, size_t bytes = T.sizeof)(ref
R range).
// run-time equivalent
T read(T, Endian endianness = Endian.bigEndian, R)(ref R range, size_t bytes =
T.sizeof).
-
'read' would ensure 'bytes' does not exceed T.sizeof, but it would allow the
bytes to be smaller than T.sizeof. The usage would be:
-
import std.bitmanip;
// run-time version
uint u = range.read!(uint, Endian.littleEndian)(3);
// or for the compile-time version:
alias pop24bitsLE = read!(uint, Endian.littleEndian, 3);
uint u = range.pop24bitsLE();
-
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12445] std.bitmanip.read should have overloads specifying the count of bytes to read
https://d.puremagic.com/issues/show_bug.cgi?id=12445 --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-03-23 09:11:51 PDT --- Sorry, the terminology is wrong. It should say count of elements, not number of bytes. The function operates on ranges of bytes. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12442] inefficient code with scope(exit)
https://d.puremagic.com/issues/show_bug.cgi?id=12442 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-03-23 09:24:36 PDT --- Similar performance worry about scope(success); http://forum.dlang.org/thread/mailman.493.1358378360.22503.digitalmar...@puremagic.com?page=1 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9106] Rename std.random.randomShuffle as std.random.shuffle and small usage change
https://d.puremagic.com/issues/show_bug.cgi?id=9106 --- Comment #16 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2014-03-23 11:56:05 PDT --- (In reply to comment #15) I don't think a no-allocation version would be possible at all. Consider having already covered N/2 elements out of N elements. There are Choose (N, N/2) possible ways to do so. To provide the next element, and then again and again, N/2 more times, we have to remember that exact state somehow. Hence we have to store at least log (Choose (N, N/2)) bits at that moment to distinguish between the states, which is of the order N/2. I think I may have struck gold in the search for appropriate algorithms: http://gan.anu.edu.au/~brent/pd/Arndt-thesis.pdf It'll take some time to read and digest this and see if it's really a good source of potential algorithms, but I thought I'd share the reference in any case. See also: http://forum.dlang.org/post/gn3vo8$vdt$1...@digitalmars.com -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12179] [ICE](e2ir.c 1861) with array operation
https://d.puremagic.com/issues/show_bug.cgi?id=12179 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Platform|x86 |All OS/Version|Windows |All Severity|normal |regression -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9106] Rename std.random.randomShuffle as std.random.shuffle and small usage change
https://d.puremagic.com/issues/show_bug.cgi?id=9106 --- Comment #17 from Ivan Kazmenko ga...@mail.ru 2014-03-23 13:10:11 PDT --- (In reply to comment #16) (In reply to comment #15) I don't think a no-allocation version would be possible at all. Consider having already covered N/2 elements out of N elements. There are Choose (N, N/2) possible ways to do so. To provide the next element, and then again and again, N/2 more times, we have to remember that exact state somehow. Hence we have to store at least log (Choose (N, N/2)) bits at that moment to distinguish between the states, which is of the order N/2. I think I may have struck gold in the search for appropriate algorithms: http://gan.anu.edu.au/~brent/pd/Arndt-thesis.pdf It'll take some time to read and digest this and see if it's really a good source of potential algorithms, but I thought I'd share the reference in any case. See also: http://forum.dlang.org/post/gn3vo8$vdt$1...@digitalmars.com The paper looks interesting (albeit likely for other purposes), thank you for the link. Regarding randomCover, Andrei's example with an LCG is able to generate only few permutations of order n at all. There are just a few dozen bits of information if the initial state and the transition function of any LCG modulo n. Thus there will be O(Poly(n)) (say, n^3 if we choose seed, multiplier and summand arbitrarily) different permutations possibly appearing in the LCG generation process. Still, there are n! different permutations of order n. A good randomCover would be able to generate a uniformly distributed permutation of any order n, provided that the underlying random bits are uniform and independent (that is, from an ideal randomness source). I believe no algorithm would suffice to counter the proof above which states that we need to store at least n bits during the course of randomCover. And there does not seem to be much justification in providing a skewed (that is, non-uniform) randomCover in Phobos. So, I believe the solution with least allocations would be to allocate once when the randomCover struct/class is initialized (possibly with an option to reuse space given in an extra argument), and then proceed allocation-free. The downside is that it will be always Theta(n) bits, while if we knew ahead the maximum number of calls k to randomCover, Theta(k) memory would suffice. - Well, that's offtopic here. Is there a proper place to put it? A wiki discussion page, perhaps? Forum threads tend to get lost... -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12446] New: std.parallelism.amap prefer iteration to indexing
https://d.puremagic.com/issues/show_bug.cgi?id=12446 Summary: std.parallelism.amap prefer iteration to indexing Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: safety0ff.b...@gmail.com ReportedBy: safety0ff.b...@gmail.com --- Comment #0 from safety0ff.bugz safety0ff.b...@gmail.com 2014-03-23 13:36:07 PDT --- Currently std.parallelism.amap uses the random access range primitives instead of the input range primitives to traverse the per-thread slices. This matters when random access is more expensive than iteration. Iteration, if properly implemented, should always at least as fast as indexing. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12446] std.parallelism.amap prefer iteration to indexing
https://d.puremagic.com/issues/show_bug.cgi?id=12446 --- Comment #1 from safety0ff.bugz safety0ff.b...@gmail.com 2014-03-23 13:54:09 PDT --- (In reply to comment #0) This matters when random access is more expensive than iteration. Iteration, if properly implemented, should always at least as fast as indexing. It occurred to me that the cost of slicing a range could be disproportionate to indexing. Are there any use cases where this is true? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12446] std.parallelism.amap prefer iteration to indexing
https://d.puremagic.com/issues/show_bug.cgi?id=12446 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from safety0ff.bugz safety0ff.b...@gmail.com 2014-03-23 14:37:56 PDT --- https://github.com/D-Programming-Language/phobos/pull/2042 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12446] std.parallelism.amap prefer iteration to indexing
https://d.puremagic.com/issues/show_bug.cgi?id=12446 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added CC||and...@erdani.com --- Comment #3 from Andrei Alexandrescu and...@erdani.com 2014-03-23 14:54:54 PDT --- I think the differences should be negligible among the two approaches. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12446] std.parallelism.amap prefer iteration to indexing
https://d.puremagic.com/issues/show_bug.cgi?id=12446 --- Comment #4 from Andrei Alexandrescu and...@erdani.com 2014-03-23 14:55:56 PDT --- ... But there's always a way to test by measuring :o). Try it on a few typical ranges. (Typical == cost of random access, if offered, shouldn't be onerous.) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12446] std.parallelism.amap prefer iteration to indexing
https://d.puremagic.com/issues/show_bug.cgi?id=12446 --- Comment #5 from safety0ff.bugz safety0ff.b...@gmail.com 2014-03-23 15:26:51 PDT --- (In reply to comment #4) ... But there's always a way to test by measuring :o). Try it on a few typical ranges. (Typical == cost of random access, if offered, shouldn't be onerous.) It's not typical array-like random access ranges that will benefit, it's atypical ones where iteration is simple but indexing is non-trivial. For example, my triangular random access range which returns the tuples: [0, 0], [1, 0], [1, 1], [2, 0], [2, 1], [2, 2], [3, 0], [3, 1], [3, 2], [3, 3] Iteration is simple, but indexing involves solving a quadratic + some other operations. Even though one might not call this onerous, there is still enough relative difference for it to be noticeable. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12446] std.parallelism.amap prefer iteration to indexing
https://d.puremagic.com/issues/show_bug.cgi?id=12446 --- Comment #6 from github-bugzi...@puremagic.com 2014-03-23 16:00:39 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/fc3cda0beb95d5164af5767c9f8134359968d294 Fix issue 12446 - std.parallelism.amap: prefer iteration to indexing https://github.com/D-Programming-Language/phobos/commit/35617d87b30a3bf17d3dc50bf41bac4c4627c12f Merge pull request #2042 from Safety0ff/fix12446 Fix issue 12446 - std.parallelism.amap: prefer iteration to indexing -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12447] New: variadic template functions hijack all eponymous enum and alias template overloads
https://d.puremagic.com/issues/show_bug.cgi?id=12447
Summary: variadic template functions hijack all eponymous enum
and alias template overloads
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: 2k...@gmx.net
--- Comment #0 from det 2k...@gmx.net 2014-03-23 16:27:05 PDT ---
see following example code.
the two 'test' templates work fine by themselves. if they are in the same
module, however, the eponymous enum template does not work anymore. instead the
compiler tries to instantiate the variadic template - and fails. same issue
with eponymous alias templates.
this should not happen as
o the two templates have very different signatures, i.e. completely
incompatible argument lists ( zero vs 0 arguments)
o the string parameter is more specialized than the take-all tuple
example code:
=
// cannot be used with function arguments:
enum test(string str ) = templated enum 'test' used with ~str;
// cannot be called with less than 1 function arguments:
string test (T ...)( T strs )
if( strs.length )
{
return templated function 'test' called with ~strs[0];
}
// enum epo = test!(foo);// use eponymous enum
// if commented in:
// Error: tuple T is used as a type
// in line 5 = string test (T ...)( T strs )
enum vari = test(bar);// use templated/variadic function
void main(string[] args)
{
import std.stdio;
// writeln( epo );
writeln( vari );
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12316] GIT HEAD: AA.get broken for Object VAL types
https://d.puremagic.com/issues/show_bug.cgi?id=12316 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12382] `opDollar` can't be used at CT
https://d.puremagic.com/issues/show_bug.cgi?id=12382 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12378] Compiler accepts any syntactically-valid code inside double-nested map predicate
https://d.puremagic.com/issues/show_bug.cgi?id=12378 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9515] UFCS fails with local aliases
https://d.puremagic.com/issues/show_bug.cgi?id=9515 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Kenji Hara k.hara...@gmail.com 2014-03-23 17:15:58 PDT --- UFCS is not designed to work for local symbols. http://dlang.org/function#pseudo-member -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11461] `Error`s are not thrown as `pure nothrow` functions are optimized out with -O -release
https://d.puremagic.com/issues/show_bug.cgi?id=11461 --- Comment #16 from github-bugzi...@puremagic.com 2014-03-23 18:11:42 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/2a50ceabb436d150ee4e6bfff299def58bc9e92c Merge pull request #753 from rainers/workaround_bug11461 Workaround 11461: avoid strong purity inference by passing null pointer to onOutOfMemoryError -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9515] UFCS fails with local aliases
https://d.puremagic.com/issues/show_bug.cgi?id=9515 --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2014-03-23 18:28:11 PDT --- UFCS is not designed to work for local symbols. It may very well be an enhancement rather than a bug to get it working with local symbols, but given that we're trying to make it so that there's no real difference between local imports and module-level imports (aside from the scope of the import), I'd say that we should definitely get UFCS working with local imports. It follows the whole turtles all the way down principle that we're generally striving for. Certainly, I don't know why we wouldn't implement this. It should simply be a question of someone taking the initiative to get it done rather than whether we should do it or not. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9515] UFCS fails with local aliases
https://d.puremagic.com/issues/show_bug.cgi?id=9515
--- Comment #5 from Kenji Hara k.hara...@gmail.com 2014-03-23 18:45:17 PDT ---
(In reply to comment #4)
UFCS is not designed to work for local symbols.
[snip]
Certainly, I don't know why we wouldn't implement this.
My concern case is:
import std.array;
struct MyRange(E) {
E[] data;
E front() {
return data.front;
// If UFCS could see local symbols, the inner-most 'front' will be
chosen
// and this line will be rewritten to this.front(data).
}
}
Note that, in symbol lookup phase function static-ness is not considered.
Because functions could be overloaded, and it should be resolved in later
phase.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12448] in argument for std.string.toStringz
https://d.puremagic.com/issues/show_bug.cgi?id=12448 --- Comment #1 from bearophile_h...@eml.cc 2014-03-23 20:17:01 PDT --- To avoid future possible problems with scope, using const string s is also enough. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12448] New: in argument for std.string.toStringz
https://d.puremagic.com/issues/show_bug.cgi?id=12448
Summary: in argument for std.string.toStringz
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-03-23 20:15:27 PDT ---
The signature of the second overload of toStringz is:
immutable(char)* toStringz(string s) @trusted pure nothrow
If you replace it with:
immutable(char)* toStringz(in string s) @trusted pure nothrow
Then the compiler gets able to catch some not used result bugs:
import std.exception: assumeUnique;
import core.stdc.string: memcmp, strlen;
import std.array: empty;
immutable(char)* toStringz(const(char)[] s) @trusted pure nothrow {
auto copy = new char[s.length + 1];
copy[0 .. s.length] = s[];
copy[$ - 1] = '\0';
return assumeUnique(copy).ptr;
}
immutable(char)* toStringz(in string s) @trusted pure nothrow {
if (s.empty)
return .ptr;
immutable p = s.ptr + s.length;
if ((cast(size_t) p 3) *p == 0)
return s.ptr;
return toStringz(cast(const char[]) s);
}
void main() {
string foo;
foo.toStringz; // Warning
}
test.d(32,8): Warning: Call to strictly pure function test.toStringz discards
return value of type immutable(char)*, prepend a cast(void) if intentional
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12413] Infinite recursion of `Package::search`
https://d.puremagic.com/issues/show_bug.cgi?id=12413 kekeni...@yahoo.co.jp changed: What|Removed |Added CC||kekeni...@yahoo.co.jp --- Comment #2 from kekeni...@yahoo.co.jp 2014-03-23 20:54:12 PDT --- https://github.com/D-Programming-Language/dmd/pull/3395 #2256 has been reverted. So the issue should be closed. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12446] std.parallelism.amap prefer iteration to indexing
https://d.puremagic.com/issues/show_bug.cgi?id=12446 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12444] std.array uninitializedArray minimallyInitializedArray missing APPENDABLE attribute / capacity info
https://d.puremagic.com/issues/show_bug.cgi?id=12444 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from safety0ff.bugz safety0ff.b...@gmail.com 2014-03-23 21:30:08 PDT --- https://github.com/D-Programming-Language/phobos/pull/2044 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
