[Issue 5549] [64-bit] Internal error: backend/cgcod.c 1845
http://d.puremagic.com/issues/show_bug.cgi?id=5549 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don 2011-02-08 23:12:53 PST --- This sounds quite similar to bug 5455. Both involve register allocation and a complicated and fragile code sequence. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5552] std.datetime.d DosFileTimeToSysTime has a bug
http://d.puremagic.com/issues/show_bug.cgi?id=5552 Jonathan M Davis changed: What|Removed |Added Status|NEW |ASSIGNED CC||jmdavisp...@gmx.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5553] New: Tables get doubled with the new std.ddoc
http://d.puremagic.com/issues/show_bug.cgi?id=5553 Summary: Tables get doubled with the new std.ddoc Product: D Version: unspecified Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis 2011-02-08 21:16:11 PST --- For some reason, the rows in the tables in the generated documentation get doubled with the new std.ddoc which Andrei has been working on for www.d-programming-language.org. For instance, look at opCmp on http://www.d-programming-language.org/phobos/std_datetime.html . It should have 3 rows, but it has 6. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5552] New: std.datetime.d DosFileTimeToSysTime has a bug
http://d.puremagic.com/issues/show_bug.cgi?id=5552
Summary: std.datetime.d DosFileTimeToSysTime has a bug
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: soar...@yeah.net
--- Comment #0 from soar...@yeah.net 2011-02-08 18:49:15 PST ---
import
std.datetime,
std.stdio;
void main()
{
auto time = cast(DosFileTime)0x3E3F8456;
writeln(DosFileTimeToSysTime(time)); //output should: 2011-Jan-31 16:34:44
}
Compile and run above snipplet, will get an exception.
Solution: change std.datetime.d at line 31820 from
int month = ((dt >> 21) & 0x0F) - 1; // 1..12
to
int month = ((dt >> 21) & 0x0F); // 1..12
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5549] [64-bit] Internal error: backend/cgcod.c 1845
http://d.puremagic.com/issues/show_bug.cgi?id=5549 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2011-02-08 17:08:59 PST --- (In reply to comment #0) > This is another insanely hard to reproduce bug. As (I think) Don has said, back-end bugs are often harder to locate. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5550] New: std.range.enumerate()
http://d.puremagic.com/issues/show_bug.cgi?id=5550
Summary: std.range.enumerate()
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 2011-02-08 17:01:39 PST ---
I suggest to add an enumerate() to Phobos std.range module. An alternative name
is count().
enumerate() is a simple function, it takes one iterable and returns an iterable
of (index, item) pairs:
>>> list(enumerate("abcd"))
[(0, 'a'), (1, 'b'), (2, 'c'), (3, 'd')]
A second optional argument allows to define a start value different from zero:
>>> list(enumerate("abcd", 3))
[(3, 'a'), (4, 'b'), (5, 'c'), (6, 'd')]
This is an example usage of Python2.6 enumerate():
>>> comp = [1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1]
>>> [i for i,b in enumerate(comp) if not b]
[2, 3, 5, 7, 11, 13, 17, 19]
>>> comp = comp[2:]
>>> comp
[0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1]
>>> [i for i,b in enumerate(comp, 2) if not b]
[2, 3, 5, 7, 11, 13, 17, 19]
Here the input 'comp' is a list of bits (booleans) produced by a Sieve of
Eratosthenes, that represents the composite numbers. The desired output (a
sequence of primes) is a list of indexes where the value b is false, so it's
prime.
This is a D2 translation in procedural style:
import std.stdio;
void main() {
auto comp = [1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0,
1];
int[] result;
foreach (i, p; comp)
if (!p)
result ~= i;
writeln(result);
comp = comp[2..$];
result.length = 0;
foreach (i, p; comp)
if (!p)
result ~= i + 2;
writeln(result);
}
A translation in functional style:
import std.stdio, std.algorithm, std.range;
void main() {
auto comp = [1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0,
1];
auto result1 = map!q{a[0]}(filter!q{!a[1]}(zip(iota(comp.length), comp)));
writeln(result1);
comp = comp[2..$];
auto result2 = map!q{a[0]+2}(filter!q{!a[1]}(zip(iota(comp.length),
comp)));
writeln(result2);
}
An enumerate() allows to write simpler code:
import std.stdio, std.algorithm, std.range;
void main() {
auto comp = [1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0,
1];
auto result1 = map!q{a[0]}(filter!q{!a[1]}(enumerate(comp)));
writeln(result1);
comp = comp[2..$];
auto result2 = map!q{a[0]}(filter!q{!a[1]}(enumerate(comp, 2)));
writeln(result2);
}
zip(iota(foo.length), foo) becomes even worse when the iterable foo is lazy and
doesn't define a length:
zip(iota(walkLength(foo)), foo)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5551] New: opUnary-opBinary conflict
http://d.puremagic.com/issues/show_bug.cgi?id=5551
Summary: opUnary-opBinary conflict
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-02-08 17:04:36 PST ---
I think this is correct code (trouble originally found by Charles McAnany):
struct Foo {
Foo opUnary(string op:"++")() {
return this;
}
Foo opBinary(string op)(int y) {
return this;
}
}
void main() {
auto f = Foo();
f++;
}
But DMD 2.051 shows the errors:
test.d(11): Error: template test.Foo.opBinary(string op) does not match any
function template declaration
test.d(11): Error: template test.Foo.opBinary(string op) cannot deduce template
function from argument types !()()
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5549] New: [64-bit] Internal error: backend/cgcod.c 1845
http://d.puremagic.com/issues/show_bug.cgi?id=5549
Summary: [64-bit] Internal error: backend/cgcod.c 1845
Product: D
Version: D2
Platform: x86_64
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha 2011-02-08 16:55:28 PST ---
This is another insanely hard to reproduce bug. The following code produces a
"Internal error: backend/cgcod.c 1845" only when compiled with -O -inline
-release -unittest -m64. I reduced it as far as I could. All of the seemingly
unnecessary stuff is actually necessary for reproducing this bug. Also, when I
copy/paste the implementation of Map into the same module as the code below, it
seems to prevent the bug from being reproduced.
import std.algorithm;
void cleanUp() {}
void doStuff(T)(T data) {
scope(exit) cleanUp(); // Taking this out gets rid of the bug.
size_t N = 0;
foreach(i, rng; data) { // Taking this loop out gets rid of the bug.
auto rngLen = rng.length;
N += rngLen;
}
int[] dataArray;
size_t pos = 0;
foreach(rng; data) { // This loop is necessary.
foreach(elem; rng) {
dataArray[pos] = elem;
pos++;
}
}
double rBar = 0.5 * (N + 1); // Even this line is necessary.
}
void main() {
// Only happens on instantiations with Map.
doStuff(
[map!"a"([3,1,4,1])]
);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4716] std.stdio.input() or similar
http://d.puremagic.com/issues/show_bug.cgi?id=4716
--- Comment #2 from bearophile_h...@eml.cc 2011-02-08 13:13:01 PST ---
Adam Ruppe has suggested:
> I'd say make it do a combination of writef though, so you can do more
> complex prompts.
>
> auto number = ask!int("Enter a number, %s", name);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5548] Efficient std.conv.to conversions
http://d.puremagic.com/issues/show_bug.cgi?id=5548 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer 2011-02-08 12:52:10 PST --- Do we not have the functionality for this (at least for strings) in std.format? Are there use cases for this beyond strings? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5548] New: Efficient std.conv.to conversions
http://d.puremagic.com/issues/show_bug.cgi?id=5548 Summary: Efficient std.conv.to conversions Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: tomeks...@gmail.com --- Comment #0 from Tomasz Sowiński 2011-02-08 12:47:58 PST --- Currently most to!T conversions allocate behind the scenes. I propose that the conversions where T is dynamically sized (like an array) get a speedy overload of the form: void to(T, S, O)(S source, O output) if (isOutputRange!(O, T)); Example: to!string(9234820934, appender); For further investigation: consider assuming the output range to be buffered. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5547] Improve assert to give information on values given to it when it fails
http://d.puremagic.com/issues/show_bug.cgi?id=5547 --- Comment #2 from Steven Schveighoffer 2011-02-08 10:57:27 PST --- Is it too difficult for this to apply only inside unit tests? I mean literally within unit test blocks. This means asserts triggered in non-unit test blocks will not report the extra info, even if called from a unit test block. But I believe this is equivalent to the original proposal of assertPred (which would only be used inside unittest blocks). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5547] Improve assert to give information on values given to it when it fails
http://d.puremagic.com/issues/show_bug.cgi?id=5547 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 2011-02-08 10:49:00 PST --- There's one difficult issue in this: this assert behaviour is not always desirable, especially outside of unittests. You have to save a copy of the parameters to assert, and that can be quite expensive -- extremely expensive, in some cases. And, you also need to be able to print them out, which creates the risk of recursion, and potentially links in a huge amount of code. The basic idea of making assert() be syntax sugar for an internal function which behaves like your assertPred() does not seem too difficult. But knowing *when* to do it is difficult. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5547] New: Improve assert to give information on values given to it when it fails
http://d.puremagic.com/issues/show_bug.cgi?id=5547
Summary: Improve assert to give information on values given to
it when it fails
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis 2011-02-08 07:47:45
PST ---
Right now, assert gives no useful information beyond the file and line number
where the failure occurred. It really should give information on what the
failure was. The recent attempt at getting assertPred in Phobos was to fix
this, but it was decided that it would be better to fix assert to do it. So,
essentially, when asserts like
assert(a == b);
assert(a.canFind(b));
fails, it should print out what the arguments to the expression were. For
instance, take this from the assertPred docs:
assert(collectExceptionMsg!AssertError(
assertPred!"=="("hello", "goodbye")) ==
`assertPred!"==" failed:` ~ "\n" ~
`[hello] (lhs)` ~ "\n" ~
`[goodbye] (rhs).`);
On failure assertPred would print out that == failed and that the values given
to it were hello and goodbye. Ideally, assert("hello" == "goodbye"); would
print something similar.
Another example would be
assert(collectExceptionMsg!AssertError(
assertPred!((int a, int b, int c, float d){return a * b < c * d;})
(22, 4, 5, 1.7)) ==
`assertPred failed: arguments: [22], [4], [5], [1.7].`);
Something similar to this - such as
assert((int a, int b, int c, float d){return a * b < c * d;}(22, 4, 5, 1.7));
or
assert(22 * 4 < 5 * 1.7);
- should print something similar to what assertPred printed.
Exactly what the best format should be and exactly what values will be best for
assert to print for more complicated expressions, I don't know - that will
depend on what is reasonable to implement - but assert should at least make a
valiant attempt at printing what the values in the expression were that failed
so that the programmer has sufficient debugging information not to have to go
and add a debug statement to print out the arguments, because the assert didn't
give enough information to properly debug the failure.
Also, it was pointed out that assertPred should print values such that they
line up on separate lines so that they're easier to compare (which it does in
the == case, though not in the case of the more general predicate - perhas it
should have). So, it would probably be a good idea for assert to do something
similar.
These improvements need to be made for assert to be properly usable for unit
tests. Otherwise, we're really going to need to add something like assertPred
to Phobos.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4360] Allow intrinsics in core.bitop to operate as intrinsics
http://d.puremagic.com/issues/show_bug.cgi?id=4360 Don changed: What|Removed |Added Keywords|patch | CC||clugd...@yahoo.com.au --- Comment #5 from Don 2011-02-08 05:00:41 PST --- Removing patch keyword since it doesn't have a patch :o -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1170] Cannot forward reference a type defined in a MixinStatement
http://d.puremagic.com/issues/show_bug.cgi?id=1170 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #8 from Don 2011-02-08 04:37:34 PST --- The test case in comment 7 was fixed in 2.051 and 1.066. The original test case still doesn't work. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5546] Assigning and initializing structs from functions make more copies than necessary
http://d.puremagic.com/issues/show_bug.cgi?id=5546
--- Comment #2 from akb...@gmail.com 2011-02-08 00:42:20 PST ---
After thinking about the problem a bit more, I have a couple things to add.
First, I should mention my second point for assigning the return value of a
function to an existing struct applies to all temporaries.
Test testVal;
testVal = Test("str");
can benefit from the same optimizations as
Test testVal;
testVal = function();
Second, it would be very useful to be able to mark the custom assignment
operator to have the same behavior on the above two cases as if there is no
overloaded assignment operator. (aka: skip the assignment and reduce it to a
blit + post blit and destruction of the old value when assigning from a
temporary) I would suggest something like putting "@ignoreIfTemp" before the
opAssign definition, and would be ignored if members of the struct have custom
assignment operators without that property. This would allow one of the most
useful benefits of rvalue references from C++0x to be used without having to
add a whole new type qualifier.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4092] broken memory management for COM objects derived from IUnknown
http://d.puremagic.com/issues/show_bug.cgi?id=4092
--- Comment #4 from Rainer Schuetze 2011-02-08 00:41:49
PST ---
The problem with allocating COM objects from the C-heap is that they cannot be
free'd inside Release() due to possible invariants being called after that.
Here's the implementation of Release in std.c.windows.com:
ULONG Release()
{
LONG lRef = InterlockedDecrement(&count);
if (lRef == 0)
{
// free object
// If we delete this object, then the postinvariant called upon
// return from Release() will fail.
// Just let the GC reap it.
//delete this;
return 0;
}
return cast(ULONG)lRef;
}
The comment even implies that the memory should be taken from the GC.
Also, any object that has references into other memory blocks needs to add
itself as a root to the GC, which can be very easily forgotten (e.g. if the
references are just strings).
As reported lately, the juno project
(http://www.dsource.org/projects/juno/wiki, probably the largest project trying
to embrace COM), works similar as proposed here. (
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=128956
)
Agreed, changing this might break some code, but probably most applications
creating COM objects have overloaded new anyway.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
