[Issue 6730] std.algorithm.splitter conflicts with std.array.splitter
http://d.puremagic.com/issues/show_bug.cgi?id=6730 --- Comment #3 from Jonathan M Davis 2012-10-22 23:16:16 PDT --- I find it highly unlikely that they'd be using it by mistake, but since it's undocumented, it's not unreasonable to break code that's using it. However, it's probably still better to deprecate it first rather than outright remove it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7689] splitter() on ivalid UTF-8 sequences
http://d.puremagic.com/issues/show_bug.cgi?id=7689
monarchdo...@gmail.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||monarchdo...@gmail.com
AssignedTo|nob...@puremagic.com|monarchdo...@gmail.com
--- Comment #1 from monarchdo...@gmail.com 2012-10-22 23:06:22 PDT ---
(In reply to comment #0)
> Is this difference/inconsistency between split() and splitter() desired and
> good?
>
>
> import std.string, std.array, std.algorithm, std.range;
> void main() {
> char[] s = cast(char[])[131, 64, 32, 251, 22];
> assert(std.string.split(s).length == 2); // no error
> assert(walkLength(std.array.splitter(s)) == 2); // Invalid UTF-8 sequence
> assert(walkLength(std.algorithm.splitter(s)) == 2); // Invalid UTF-8
> sequence
> }
>
>
> Output, DMD 2.059head:
>
> std.utf.UTFException@std\utf.d(645): Invalid UTF-8 sequence (at index 1)
>
> ...\dmd2\src\phobos\std\array.d(469): dchar
> std.array.front!(char[]).front(char[])
> ...\dmd2\src\phobos\std\algorithm.d(2110): D3std9algorithm47__T8splitterS28...
> ...\dmd2\src\phobos\std\range.d(971): D3std5range97__...
>
This is a bug in string.split (which is actually a public import of
array.split).
Currently array.split only supports ascii white, and is oblivious to longer utf
whites (but it does work on unicode).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6730] std.algorithm.splitter conflicts with std.array.splitter
http://d.puremagic.com/issues/show_bug.cgi?id=6730 --- Comment #2 from monarchdo...@gmail.com 2012-10-22 23:09:27 PDT --- (In reply to comment #1) > In general, I'd say yes. The fact that two functions in different modules can > have the same name and conflict is fully expected and acceptable. The module > system gives a number of ways to get around the problem. That's not an issue. > > However, in this case, what appears to be happening is that we have almost > identical functions in two modules. The only difference between them is that > the one in std.array will work with immutable strings, since it specifically > types itself as taking an array, whereas std.algorithm's types itself as > taking > a range (though the range must be a string per the template constraint). If > they did different things, that would be one thing, but I see no reason to > have > two identical functions. One of the two should be scheduled for deprecation. Assigned to self. Note that the one in std.algorithm is not documented, so anybody using it is probably doing it by mistake. My I outright remove it? Should I straight up give it deprecate it now? Do I have to go the full deprecation route? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6730] std.algorithm.splitter conflicts with std.array.splitter
http://d.puremagic.com/issues/show_bug.cgi?id=6730 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||monarchdo...@gmail.com AssignedTo|nob...@puremagic.com|monarchdo...@gmail.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8765] assert should print the source code for the condition when no message argument present
http://d.puremagic.com/issues/show_bug.cgi?id=8765 Andrej Mitrovic changed: What|Removed |Added CC||tim.dolo...@gmail.com --- Comment #6 from Andrej Mitrovic 2012-10-22 21:00:45 PDT --- *** Issue 8058 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8058] assert(false) displays incomplete filename
http://d.puremagic.com/issues/show_bug.cgi?id=8058 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #1 from Andrej Mitrovic 2012-10-22 21:00:45 PDT --- Pull for Issue 8765 will incorporate this. *** This issue has been marked as a duplicate of issue 8765 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8875] New: can't remove() in case of static associated array
http://d.puremagic.com/issues/show_bug.cgi?id=8875
Summary: can't remove() in case of static associated array
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: hotcocoa...@gmail.com
--- Comment #0 from hotcocoa...@gmail.com 2012-10-22 20:37:40 PDT ---
example code ( no error ):
void main(){
C c;
c = new C(0);
delete c;
}
class C{
static int[int] staticList;
int myint;
this( int x ){
staticList[x] = 1;
myint = x;
}
~this(){
staticList.remove( myint );
}
}
BUT comment out "delete c;" , freeze by end of runtime.
in addition,
code that only refer to staticList did'nt freeze.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5269] version(assert)
http://d.puremagic.com/issues/show_bug.cgi?id=5269 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4565] In array literals single values can replace arrays of length 1
http://d.puremagic.com/issues/show_bug.cgi?id=4565 --- Comment #2 from bearophile_h...@eml.cc 2012-10-22 16:26:08 PDT --- (In reply to comment #1) > Do you by any chance have a somewhat elaborate set of test-cases that cover > many types of arrays which should and shouldn't compile? I don't, sorry. Currently finding such test cases is a laborious manual work. There is no fuzzy testing framework for D, as ones used on the certified C compiler. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4565] In array literals single values can replace arrays of length 1
http://d.puremagic.com/issues/show_bug.cgi?id=4565 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2012-10-22 16:00:17 PDT --- Do you by any chance have a somewhat elaborate set of test-cases that cover many types of arrays which should and shouldn't compile? It would help to make solid test-cases. Otherwise I'll write them myself, no problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8874] New: Possible warning for always true/always false comparisons on unsigned values
http://d.puremagic.com/issues/show_bug.cgi?id=8874
Summary: Possible warning for always true/always false
comparisons on unsigned values
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-10-22 15:33:11 PDT ---
This small C program solves a common Subset sum problem:
http://rosettacode.org/wiki/Subset_sum_problem
// C code starts here
#include
#include
typedef struct { char* data; int weight; } item;
typedef struct { int sum; unsigned int mask; } sum_t;
item em[] = {
{"alliance",-624}, {"archbishop", -915}, {"balm", 397},
{"bonnet", 452}, {"brute",870}, {"centipede", -658},
{"cobol",362}, {"covariate",590}, {"departure",952},
{"deploy",44}, {"diophantine", 645}, {"efferent", 54},
{"elysee", -326}, {"eradicate",376}, {"escritoire", 856},
{"exorcism",-983}, {"fiat", 170}, {"filmy", -874},
{"flatworm", 503}, {"gestapo", 915}, {"infra", -847},
{"isis",-982}, {"lindholm", 999}, {"markham", 475},
{"mincemeat", -880}, {"moresby", 756}, {"mycenae", 183},
{"plugging",-266}, {"smokescreen", 423}, {"speakeasy", -745},
{"vein", 813}
};
#define N (sizeof(em)/sizeof(em[0]))
int cmp_sums(const void *a, const void *b)
{
return ((sum_t*)a)->sum - ((sum_t*)b)->sum;
}
sum_t *mksums(item *p, int n, int shift)
{
sum_t *r = malloc(sizeof(*r) * (1 << n));
int i;
for (i = 0; i < n; i++)
r[1< j1; y--)
showmask(l[x].mask | r[y].mask);
return s;
}
i = 0, j = N2 - 1;
while (1) {
while (l[i].sum + r[j].sum) {
while (i < N1 && l[i].sum + r[j].sum < 0) i++;
while (j >= 0 && l[i].sum + r[j].sum > 0) j--;
if (i >= N1 || j < 0) break;
}
if (i >= N1 || j < 0) break;
for (i1 = i + 1; i1 < N1 && l[i1].sum == l[i].sum; i1++);
for (j1 = j - 1; j1 >= 0 && r[j1].sum == r[j].sum; j1--);
sols += printlist();
i = i1, j = j1;
}
printf("zero sums: %d\n", sols);
return 0;
}
// C code ends here
The i, j, i1, j1 variables are used as array indexes, so to "improve" the code
I am willing to try replacing the line of code:
int i, j, i1, j1;
With:
size_t i, j, i1, j1;
Compiling with GCC 4.7.1, using "-Wall -Wextra", it produces the warnings:
temp.c: In function 'showmask':
temp.c:59:28: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
temp.c: In function 'printlist':
temp.c:71:27: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
temp.c:72:27: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
temp.c: In function 'main':
temp.c:80:22: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
temp.c:81:13: warning: comparison of unsigned expression >= 0 is always true
[-Wtype-limits]
temp.c:82:19: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
temp.c:82:13: warning: comparison of unsigned expression < 0 is always false
[-Wtype-limits]
temp.c:84:15: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
temp.c:84:9: warning: comparison of unsigned expression < 0 is always false
[-Wtype-limits]
temp.c:86:29: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
temp.c:87:9: warning: comparison of unsigned expression >= 0 is always true
[-Wtype-limits]
Here the warning messages generated by "-Wtype-limits" save me from those bugs
caused by refactoring.
With DMD 2.061alpha using the "-wi" compilation switch this code gives no
warning messages:
// D code
int foo(uint x, uint y) {
uint count = 0;
if (x >= 0)
count++;
if (y < 0)
count++;
return count;
}
void main() {}
In this little foo() function it's easy to see the problems, but in a large
function it's more easy to miss the mistake of using unsigned x and y with
those comparisons that are always false or always true.
So consider the possibility of adding such warning to D/DMD.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8873] New: Some class field reordering for emplacing?
http://d.puremagic.com/issues/show_bug.cgi?id=8873
Summary: Some class field reordering for emplacing?
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-10-22 15:14:21 PDT ---
According to the specs D classes are free to reorder their fields:
>The D compiler is free to rearrange the order of fields in a class to
>optimally pack them in an implementation-defined manner.<
So in this program maybe Bar1 should reorder its fields as Bar3, to save 4
bytes for each instance on 32 bit systems:
class Bar1 {
void Hello() {}
float f;
double d;
}
class Bar2 {
void Hello() {}
align(4) float f;
align(4) double d;
}
class Bar3 {
void Hello() {}
double d;
float f;
}
void main() {
pragma(msg, __traits(classInstanceSize, Bar1)); // 24 bytes
pragma(msg, __traits(classInstanceSize, Bar2)); // 20 bytes
pragma(msg, __traits(classInstanceSize, Bar3)); // 20 bytes
}
This benchmark shows that if you allocate the class instances on the heap one
at a time the total amount of memory used is the same for the various Bar
(because of the GC, it allocates 32 bytes for each class instance of Bar1, Bar2
or Bar3), so that optimization is useful for emplace() only and similar
in-place allocations:
class Bar1 {
void Hello() {}
float f;
double d;
}
class Bar2 {
void Hello() {}
align(4) float f;
align(4) double d;
}
class Bar3 {
void Hello() {}
double d;
float f;
}
int main() {
pragma(msg, __traits(classInstanceSize, Bar1)); // 24
pragma(msg, __traits(classInstanceSize, Bar2)); // 20
pragma(msg, __traits(classInstanceSize, Bar3)); // 20
//--
//auto arr = new Bar1[1_000_000]; // 38.2 MB
//auto arr = new Bar2[1_000_000]; // 38.2 MB
auto arr = new Bar3[1_000_000]; // 38.2 MB
foreach (ref a; arr)
a = new typeof(arr[0])();
int count;
foreach (i; 0 .. 500_000_000) count++;
return count;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8013] splitter() and split() give different results
http://d.puremagic.com/issues/show_bug.cgi?id=8013 --- Comment #2 from bearophile_h...@eml.cc 2012-10-22 15:12:56 PDT --- (In reply to comment #1) > Taking this too. Any other split-related bug I missed? I don't know what you have missed, but see also: http://d.puremagic.com/issues/show_bug.cgi?id=4764 http://d.puremagic.com/issues/show_bug.cgi?id=5838 http://d.puremagic.com/issues/show_bug.cgi?id=6730 http://d.puremagic.com/issues/show_bug.cgi?id=7689 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8872] Missing extended window styles (WS_EX_... enumeration) in windows header
http://d.puremagic.com/issues/show_bug.cgi?id=8872 Alex R�nne Petersen changed: What|Removed |Added Keywords||pull Status|NEW |ASSIGNED CC||a...@lycus.org AssignedTo|nob...@puremagic.com|a...@lycus.org --- Comment #1 from Alex R�nne Petersen 2012-10-22 23:35:14 CEST --- https://github.com/D-Programming-Language/druntime/pull/334 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8872] New: Missing extended window styles (WS_EX_... enumeration) in windows header
http://d.puremagic.com/issues/show_bug.cgi?id=8872 Summary: Missing extended window styles (WS_EX_... enumeration) in windows header Product: D Version: unspecified Platform: All OS/Version: Windows Status: NEW Severity: minor Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: maidenp...@hotmail.com --- Comment #0 from Phil Lavoie 2012-10-22 14:03:36 PDT --- The core.sys.windows.windows header provides the values for the windows class style enumeration (WS_...) used in conjunction with the WNDCLASSA struct and the CreateWindowA function. However, the extended values for the WNDCLASSEXA and CreateWindowExA struct is not provided (first parameter to the function). Here is the link listing those: http://msdn.microsoft.com/en-us/library/windows/desktop/ff700543(v=vs.85).aspx Cheers! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8871] Missing the RegisterClassExA function declaration in the windows header.
http://d.puremagic.com/issues/show_bug.cgi?id=8871 Alex R�nne Petersen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8013] splitter() and split() give different results
http://d.puremagic.com/issues/show_bug.cgi?id=8013 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||monarchdo...@gmail.com AssignedTo|nob...@puremagic.com|monarchdo...@gmail.com --- Comment #1 from monarchdo...@gmail.com 2012-10-22 13:49:14 PDT --- Taking this too. Any other split-related bug I missed? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8871] Missing the RegisterClassExA function declaration in the windows header.
http://d.puremagic.com/issues/show_bug.cgi?id=8871 Alex R�nne Petersen changed: What|Removed |Added Keywords||pull Status|NEW |ASSIGNED CC||a...@lycus.org AssignedTo|nob...@puremagic.com|a...@lycus.org --- Comment #1 from Alex R�nne Petersen 2012-10-22 22:36:47 CEST --- https://github.com/D-Programming-Language/druntime/pull/333 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8871] New: Missing the RegisterClassExA function declaration in the windows header.
http://d.puremagic.com/issues/show_bug.cgi?id=8871 Summary: Missing the RegisterClassExA function declaration in the windows header. Product: D Version: unspecified Platform: All OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: maidenp...@hotmail.com --- Comment #0 from Phil Lavoie 2012-10-22 13:32:05 PDT --- You can find the RegisterClassA function in the windows header (core.system.windows.windows) but not the equivalent version for the WNDCLASSEXA structure. However, declaring it like this: extern( Windows ) export RegisterClassExA(...); And calling it Works fine for me (compiles and links, so the function definition is found). I think the solution is simply a matter of adding it to the windows header. I am using DMD 2.060 on my machine. Cheers! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5570] 64 bit C ABI not followed for passing structs and complex numbers as function parameters
http://d.puremagic.com/issues/show_bug.cgi?id=5570 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #32 from Andrej Mitrovic 2012-10-22 12:47:53 PDT --- (In reply to comment #30) > Progress at DMD1.075/2.060 beta2: > This now works for structs which contain integral types only, or which contain > floating point types only. It doesn't work if you have an int member and a > float member. http://dpaste.dzfl.pl/f1ac00d2 Output is Test(5, 6, 5, 6) instead of Test(5, 6, 7, 8). It works OK if the function is extern(C). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8870] New: Incorrect values passing struct by value
http://d.puremagic.com/issues/show_bug.cgi?id=8870
Summary: Incorrect values passing struct by value
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: turkey...@gmail.com
--- Comment #0 from Manu 2012-10-22 12:39:58 PDT ---
http://dpaste.dzfl.pl/82f04399
t2 is [5, 6, 5, 6] when compiled with DMD-x64. should be [5, 6, 7, 8].
extern (C) fixes the problem.
import std.stdio;
struct Test
{
float x = 0;
float y = 0;
float z = 0;
float w = 0;
}
void main()
{
Test r1 = Test(1,2,3,4);
Test r2 = Test(5,6,7,8);
test(r1, r2, false, 1);
}
void test(Test t1, Test t2, bool someBool, float finalFloat)
{
// at this point, t2 == { 5, 6, 5, 6 }
writeln(t2);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8869] std.typecons.Unique instance doesn't compile, needs std.stdio
http://d.puremagic.com/issues/show_bug.cgi?id=8869 --- Comment #1 from earthfront 2012-10-22 09:56:32 PDT --- It appears that the import section of "std.typecons" has a conditional import statement: "version(unittest) import core.vararg, std.stdio;" but the "writeln" statements don't seem to correlate with that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8869] New: std.typecons.Unique instance doesn't compile, needs std.stdio
http://d.puremagic.com/issues/show_bug.cgi?id=8869
Summary: std.typecons.Unique instance doesn't compile, needs
std.stdio
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: earthfr...@gmail.com
--- Comment #0 from earthfront 2012-10-22 09:50:03 PDT
---
Using DMD64 v2.059 on Ubuntu 12.04 64bit:
[BEGIN EXAMPLE CODE:main.d]
void main(string[] args)
{
class Widget
{ int a; }
{
import std.typecons;
Unique!Widget uw = new Widget;
}
}
[END EXAMPLE CODE]
Results in:
$ dmd main.d
/usr/include/x86_64-linux-gnu/dmd/phobos/std/typecons.d(91): Error: 'writeln'
is not defined, perhaps you need to import std.stdio; ?
/usr/include/x86_64-linux-gnu/dmd/phobos/std/typecons.d(102): Error: 'writeln'
is not defined, perhaps you need to import std.stdio; ?
/usr/include/x86_64-linux-gnu/dmd/phobos/std/typecons.d(134): Error: 'writeln'
is not defined, perhaps you need to import std.stdio; ?
/usr/include/x86_64-linux-gnu/dmd/phobos/std/typecons.d(145): Error: 'writeln'
is not defined, perhaps you need to import std.stdio; ?
/usr/include/x86_64-linux-gnu/dmd/phobos/std/typecons.d(148): Error: 'writeln'
is not defined, perhaps you need to import std.stdio; ?
main.d(8): Error: template instance std.typecons.Unique!(Widget) error
instantiating
Including std.stdio anywhere in my program doesn't help.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3011] alias should have assignment syntax
http://d.puremagic.com/issues/show_bug.cgi?id=3011 --- Comment #5 from github-bugzi...@puremagic.com 2012-10-22 09:50:55 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/d-programming-language.org https://github.com/D-Programming-Language/d-programming-language.org/commit/2248b317d50d0ab109e3e816a0c16b05b4631bbd fix Issue 3011 - alias should have assignment syntax https://github.com/D-Programming-Language/d-programming-language.org/commit/5668f12dbb296b485df58fbcab2fc4188c30d3b9 Merge pull request #177 from 9rnsr/fix3011 Issue 3011 - alias should have assignment syntax -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3011] alias should have assignment syntax
http://d.puremagic.com/issues/show_bug.cgi?id=3011 --- Comment #4 from github-bugzi...@puremagic.com 2012-10-22 09:50:26 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/796aba2877e2db672806c2f2562e0c5a2f30ab17 fix Issue 3011 - alias should have assignment syntax https://github.com/D-Programming-Language/dmd/commit/6c01188d71433508bc4c0af6b821a97e8df2e986 Merge pull request #1187 from 9rnsr/fix3011 [enh] Issue 3011 - alias should have assignment syntax -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3850] Signed/unsigned bytes type name
http://d.puremagic.com/issues/show_bug.cgi?id=3850 --- Comment #5 from bearophile_h...@eml.cc 2012-10-22 09:52:06 PDT --- (In reply to comment #4) > That still won't prevent you from making the mistake of typing 'byte' instead > of 'ubyte' though. :) If you have sbyte and ubyte, and you keep using them consistently, I think this alone helps reduce mistakes a little. And once few years have passed, and using "byte" is considered a bad idiom, D programs in the wild use "byte" less and less, we can even consider deprecating it. There are tons of C++ code that represents null as "0", yet in C++11 there is nullptr, and G++ from version 4.7 has a warning (-Wzero-as-null-pointer-constant) that allows to find usage of "0" to represent null pointer. The most important thing is the desire to improve the situation, then some slow deprecation paths exist. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3850] Signed/unsigned bytes type name
http://d.puremagic.com/issues/show_bug.cgi?id=3850 --- Comment #4 from Andrej Mitrovic 2012-10-22 08:58:02 PDT --- (In reply to comment #3) > This is not a newbie issue. I make this mistake myself, fairly often. Absolutely, it happens to me all the time as well. > I wish we could change this. (I would do it by changing the type to "sbyte" > and > then adding "alias byte = sbyte;" to object.d). That still won't prevent you from making the mistake of typing 'byte' instead of 'ubyte' though. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8867] splitter(R1, X) strong requirements, weak support.
http://d.puremagic.com/issues/show_bug.cgi?id=8867 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|nob...@puremagic.com|monarchdo...@gmail.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019
Andrei Alexandrescu changed:
What|Removed |Added
CC||and...@metalanguage.com
--- Comment #8 from Andrei Alexandrescu 2012-10-22
08:05:52 PDT ---
Consider (assuming A has an int-accepting ctor):
A object = A(1);
// or
auto object = A(1);
In here the name of the type being constructed appears in clear, so there's no
chance for a potential confusion. The code currently works, as it should.
Consider:
A object = 1;
Again the type being constructed appears in clear. The code works in a function
but not at top level. It is a bug that it doesn't work at top level, because
the equivalent construct A object = A(1) does.
Now consider:
void fun(A) { ... }
fun(1);
In here there's no explicit mention of A in the call, which makes this case
qualitatively different from the ones above. Currently the compiler rejects the
code and I think it does very well so. Implicit conversions on function calls
is unrecommended in the presence of function overloading, and essentially C++
made a mistake about it that it has later partially fixed with the "explicit"
keyword. We won't repeat that mistake.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8862] order of declaration of a function and compile time execution
http://d.puremagic.com/issues/show_bug.cgi?id=8862 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #5 from Don 2012-10-22 07:39:56 PDT --- The difference is simply that bearophile's case is using git head. The "circular dependency" message was missing from previous compiler releases. This situation is actually a bit strange. It's using sequential semantics, as if it were in a function body, rather than the out-of-order semantics it would have in a struct. This isn't actually a CTFE bug - it should be possible to reproduce this bug without using CTFE. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8868] New: overload resolution of &x.g() incorrectly chooses delegate over function pointer
http://d.puremagic.com/issues/show_bug.cgi?id=8868
Summary: overload resolution of &x.g() incorrectly chooses
delegate over function pointer
Product: D
Version: D1 & D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2012-10-22 06:20:51 PDT ---
..or vice versa.
Reported by kenji in the pull request for bug 8257.
https://github.com/D-Programming-Language/dmd/pull/1194
-
struct S8257 {
void g(int n){} // before the static one
static int g() { return 6; }
}
void main() {
auto k = &(func()).g;
pragma(msg, typeof(k)); // prints void delegate(int n)
}
It always chooses the first function declaration.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3851] Array copy error message with no line number
http://d.puremagic.com/issues/show_bug.cgi?id=3851 --- Comment #3 from github-bugzi...@puremagic.com 2012-10-22 05:45:28 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/646f9c84320beb697baf0f13c5b12a28afd4dcc3 Fixes Issue 3851 - Print mismatching lengths for both assignments and copies. https://github.com/D-Programming-Language/druntime/commit/594613c5f028fca4778f682d02c568cac3e7ee73 Merge pull request #332 from AndrejMitrovic/Fix3851 Fix Issue 3851 - Array copy error message -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3851] Array copy error message with no line number
http://d.puremagic.com/issues/show_bug.cgi?id=3851 Alex R�nne Petersen changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8867] New: splitter(R1, X) strong requirements, weak support.
http://d.puremagic.com/issues/show_bug.cgi?id=8867 Summary: splitter(R1, X) strong requirements, weak support. Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2012-10-22 04:11:09 PDT --- The requirements for splitter(R, V) are that both R1 hasLength and that it be sliceable. Ditto for splitter!condition(R). The requirements for splitter(R1, R2) are that both R1 and R2 define the member length. That both R1 and R2 be sliceable. This restricts both from operating on infinite ranges. Splitter should be relatively well implementable with only Forward ranges. Also, none have any *actual* template restrictions -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8805] corrupt data at compile time.
http://d.puremagic.com/issues/show_bug.cgi?id=8805 Don changed: What|Removed |Added Keywords||wrong-code CC||clugd...@yahoo.com.au --- Comment #1 from Don 2012-10-22 03:17:28 PDT --- I can reproduce this on 2.060, but it seems to be fixed in github. Might be a duplicate, but it's not obvious to me which commit would have fixed this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8866] New: Splitter(R1, R2) CANNOT be bidirectional.
http://d.puremagic.com/issues/show_bug.cgi?id=8866
Summary: Splitter(R1, R2) CANNOT be bidirectional.
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2012-10-22 03:08:00 PDT ---
Because long story short: If a splitter "element" overlaps with another, the
the orientation of the splitting will influence the splitting. For example:
Given the string "aaab", and the splitter "ab":
//
import std.string;
import std.algorithm;
import std.range;
import std.stdio;
void main()
{
auto r = "aaab";
auto sep = "aa";
auto s = r.splitter(sep);
//Normal split
s.writeln();
//Split using back/popBack:
s.retro().array().retro().writeln();
}
//
Produces:
["", "ab"]
["a", "b"]
This creates two different results.
I don't have a source for this, but I'm 99% sure that iterating a range
backwards should produce the same output as the reverse of the range iterated
forward.
Suggest removing backwards iteration on splitter(R1, R2), and add suggestion to
use splitter(R1.retro, R2.retro)
Note; splitter(R, Value) and splitter(terminator)(R) should be able to safely
iterate backwards.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5977] String splitting with empty separator
http://d.puremagic.com/issues/show_bug.cgi?id=5977
monarchdo...@gmail.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||monarchdo...@gmail.com
AssignedTo|nob...@puremagic.com|monarchdo...@gmail.com
--- Comment #3 from monarchdo...@gmail.com 2012-10-22 02:52:16 PDT ---
(In reply to comment #0)
> This D2 program seems to go in infinte loop (dmd 2.053beta):
>
>
> import std.string;
> void main() {
> split("a test", "");
> }
>
>
>
> My suggestion is to add code like this in std.array.split():
>
> if (delim.length == 0)
> return split(s);
>
> This means that en empty splitting string is like splitting on generic
> whitespace. This is useful in code like:
>
> auto foo(string txt, string delim="") {
> return txt.split(delim);
> }
I think it is a bad idea on two counts:
1. If the user wanted that behavior, he'd have written it as such. If the user
actually passed a seperator that is an empty range, he probably didn't mean for
it split by spaces.
2. I think it would also bring a deviation of behavior between strings and
non-strings. Supposing r is empty:
* "hello world".split(""); //Ok, split white
* [1, 2].split(r); //Derp.
(In reply to comment #1)
> Alternative: throw an ArgumentError("delim argument is empty") exception if
> delim is empty.
I *really* think that is a *much* saner approach. Splitting with an empty
separator is just not logic. Trying to force a default behavior in that
scenario is wishful thinking (IMO).
I think it should throw an error. I'll implement this.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8551] Endless Split
http://d.puremagic.com/issues/show_bug.cgi?id=8551 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||monarchdo...@gmail.com Resolution||DUPLICATE --- Comment #5 from monarchdo...@gmail.com 2012-10-22 02:42:41 PDT --- *** This issue has been marked as a duplicate of issue 5977 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5977] String splitting with empty separator
http://d.puremagic.com/issues/show_bug.cgi?id=5977 monarchdo...@gmail.com changed: What|Removed |Added CC||daniel...@bigpond.com --- Comment #2 from monarchdo...@gmail.com 2012-10-22 02:42:42 PDT --- *** Issue 8551 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8166] retro() of splitter() too
http://d.puremagic.com/issues/show_bug.cgi?id=8166
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
AssignedTo|nob...@puremagic.com|monarchdo...@gmail.com
--- Comment #1 from monarchdo...@gmail.com 2012-10-22 02:40:24 PDT ---
(In reply to comment #0)
> This is an operation I'd like to do:
>
> import std.range, std.algorithm;
> void main() {
> auto p = std.array.splitter("this is a message").retro();
> }
>
>
> DMD 2.060alpha gives:
>
> test.d(3): Error: template std.range.retro does not match any function
> template
> declaration
> ...\dmd2\src\phobos\std\range.d(1292): Error: template std.range.retro(Range)
> if (isBidirectionalRange!(Unqual!(Range))) cannot deduce template function
> from
> argument types !()(Result)
>
>
> I think a splitter of a narrow string can be a BidirectionalRange.
I'll take this.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4082] nothrow main() can throw
http://d.puremagic.com/issues/show_bug.cgi?id=4082 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from bearophile_h...@eml.cc 2012-10-22 02:23:34 PDT --- Closed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7044] Missing a way to control the order of arguments passed to the linker makes impossible to link some programs
http://d.puremagic.com/issues/show_bug.cgi?id=7044 --- Comment #5 from Leandro Lucarella 2012-10-22 02:10:58 PDT --- (In reply to comment #4) > The problem is the order of -defaultlib and -L is fixed as: > > 1. -L flags > 2. libraries on the command line > 3. libraries specified by pragma(lib) > 4. standard libraries (also -debuglib, -defaultlib libraries) > > I suggest the straightforward approach of the order of (1), (2), and (4) be > determined by the order in which they appear on the command line. This is good enough to change the runtime in the dmd.conf file but is not ideal for overriding a default later, because the -L flags are not replaced as the -defaultlib option is, just appended. For example, I have a default runtime which needs to link to librt, so I have this in dmd.conf: DFLAGS=-defaultlib=runtime1 -L-lrt Then I want to compile some program using another runtime that depends on libz, if I write: dmd -defaultlib=runtime2 -Llz The best we can do is to get these link options: -lrt -lruntime2 -lz Which includes -lrt, which is not needed by runtime2 (and it might not even be available in the environment runtime2 is compiled). I think we need a flag to override the default runtime library *and* all its dependencies in one go. > That leaves (3), and I suggest that be inserted immediately before (4). I guess it makes sense, if you want complete control on the ordering then you have to switch to using -L instead of pragma(lib). > This may break existing build systems, though. This is one good point about the solution I proposed before, is completely backwards compatible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3850] Signed/unsigned bytes type name
http://d.puremagic.com/issues/show_bug.cgi?id=3850 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #3 from Don 2012-10-22 02:02:18 PDT --- This is not a newbie issue. I make this mistake myself, fairly often. *Walter* made this mistake once, in the header generation tool! My experience is that 90% of uses of "byte", should instead be "ubyte". It is really, really unusual to be using signed bytes. I wish we could change this. (I would do it by changing the type to "sbyte" and then adding "alias byte = sbyte;" to object.d). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4082] nothrow main() can throw
http://d.puremagic.com/issues/show_bug.cgi?id=4082 --- Comment #5 from github-bugzi...@puremagic.com 2012-10-22 00:46:53 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/748f3509827d6e0e1c1efabddc23de24aa3873e9 fix issue 4082 - Finally-block hides thrown exceptions from nothrow attribute -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3666] Enhancement Request: Mixin Templates
http://d.puremagic.com/issues/show_bug.cgi?id=3666 Jacob Carlborg changed: What|Removed |Added CC||d...@me.com --- Comment #3 from Jacob Carlborg 2012-10-22 00:03:07 PDT --- These are still valid ideas and D did had templates back in 2010. Half of the proposal is already implemented, you can prefix a template declaration with "mixin". When a template is prefix with "mixin" you cannot use it like a regular template. But you still need the "mixin" keyword when mixing in the template. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
