[Issue 4356] Copy constructor not called under extremely mysterious circumstances
http://d.puremagic.com/issues/show_bug.cgi?id=4356 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Walter Bright 2010-06-21 22:15:06 PDT --- http://www.dsource.org/projects/dmd/changeset/555 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4358] Potential Memory Leaks in std.file.read() ?
http://d.puremagic.com/issues/show_bug.cgi?id=4358 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #1 from nfx...@gmail.com 2010-06-21 21:55:39 PDT --- Congratulations, you just found out that D's GC implementation is fucking shit. There doesn't seem to be a bug in std.file.read. It just uses the GC to allocate a big chunk of memory, and returns it. There are probably false pointers. Note that the latest allocated buffer will not be free'd with fullCollect() (because you still have a reference to the buffer in that variable), but I assume imageres.dll is much smaller than 200 MB. Rule of thumb: never allocate big arrays with the GC. There's a patch in bug 3463 to alleviate the problem, but it seems to be abandoned. Though, there is one potential problem in the D2 version of std.file.read. It contains this line: auto buf = GC.malloc(size, GC.BlkAttr.NO_SCAN)[0 .. size]; buf is returned as void[] to the user. As far as I understand the recently introduced changes to array appending, the memory block for an array slice contains a hidden length field. This is not present in this case, thus random things may happen if you try to append to the returned array. I do not know if this actually is a problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2848] static if (is(type)) + alias fails to compile
http://d.puremagic.com/issues/show_bug.cgi?id=2848 Don changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #5 from Don 2010-06-21 21:04:18 PDT --- (In reply to comment #4) > Works in DMD 1.062, I don't know when it got fixed. I guess it will work in > DMD > 2.0xx, but I don't have one installed to test. > > If somebody wants to try it, this bug can be closed (maybe Don who seems to > bisect a lot and has an environment to do that easily wants to bisect DMD to > see when it got fixed and add the proper changelog entry ;). No probs. Fixed DMD 1.050. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2848] static if (is(type)) + alias fails to compile
http://d.puremagic.com/issues/show_bug.cgi?id=2848 --- Comment #4 from Leandro Lucarella 2010-06-21 17:53:23 PDT --- Works in DMD 1.062, I don't know when it got fixed. I guess it will work in DMD 2.0xx, but I don't have one installed to test. If somebody wants to try it, this bug can be closed (maybe Don who seems to bisect a lot and has an environment to do that easily wants to bisect DMD to see when it got fixed and add the proper changelog entry ;). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3578] Impossible to run a struct invariant using assert(s)
http://d.puremagic.com/issues/show_bug.cgi?id=3578 Leandro Lucarella changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from Leandro Lucarella 2010-06-21 17:44:13 PDT --- *** Issue 4326 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 4326] struct invariants documentation
http://d.puremagic.com/issues/show_bug.cgi?id=4326 Leandro Lucarella changed: What|Removed |Added Status|NEW |RESOLVED CC||llu...@gmail.com Resolution||DUPLICATE --- Comment #1 from Leandro Lucarella 2010-06-21 17:44:13 PDT --- I think this is a duplicate of bug 3578, please check if there is something missing in that bug and add it as a comment. Since both bugs are so similar I don't see a point on having both open so I'm marking it as duplicate. Please, feel free to correct me if I'm wrong. *** This issue has been marked as a duplicate of issue 3578 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4360] New: Allow intrinsics in core.bitop to operate as intrinsics
http://d.puremagic.com/issues/show_bug.cgi?id=4360 Summary: Allow intrinsics in core.bitop to operate as intrinsics Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: s...@invisibleduck.org --- Comment #0 from Sean Kelly 2010-06-21 15:10:45 PDT --- Currently, this module must import std.intrinsic to work properly. It would be nice if the compiler added these intrinsics to its lookup table to break this dependency. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4077] Bugs caused by bitwise operator precedence
http://d.puremagic.com/issues/show_bug.cgi?id=4077 --- Comment #10 from Don 2010-06-21 14:48:40 PDT --- Created an attachment (id=669) Patch against svn 552, D2 This patch implements Stewart Gordon's proposal. Quite simple, since it is just the parser. I'm not sure if there's a better way of doing it, but it still only affects a small number of lines. Most of this patch involves creating nice error messages when ambiguities occur. I have NOT dealt with the code in the 'global.params.Dversion == 1' block inside parseAndExp(). I don't know if it's current; in any case it's completely different to the code in D1. Possibly this needs to change as well, for code inside version(D1) blocks. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4077] Bugs caused by bitwise operator precedence
http://d.puremagic.com/issues/show_bug.cgi?id=4077 Don changed: What|Removed |Added Keywords||patch Version|future |D2 --- Comment #11 from Don 2010-06-21 14:49:58 PDT --- Note that with this patch in place, I found 6 bugs in Phobos and 1 in druntime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3804] Recent versions of GNU C Library have execvpe() implemented.
http://d.puremagic.com/issues/show_bug.cgi?id=3804 Lars T. Kyllingstad changed: What|Removed |Added CC||bugzi...@kyllingen.net Severity|blocker |enhancement --- Comment #1 from Lars T. Kyllingstad 2010-06-21 11:47:31 PDT --- Please correct me if I'm wrong, but I don't see how this bug can be a blocker. Is std.process not working for you? If so, it would be great if you could provide a test case. Until then, I'm marking this as an enhancement request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3532] benchmark function consumes 100% CPU when used with anonymous delegate
http://d.puremagic.com/issues/show_bug.cgi?id=3532 Lars T. Kyllingstad changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||bugzi...@kyllingen.net Resolution||INVALID --- Comment #2 from Lars T. Kyllingstad 2010-06-21 11:41:16 PDT --- This is not a Phobos issue, it's a bug in DMD. I've reported it with a reduced test case, see issue 4359. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4359] New: Erroneous behaviour of variables in a delegate literal passed as template tuple parameter
http://d.puremagic.com/issues/show_bug.cgi?id=4359
Summary: Erroneous behaviour of variables in a delegate literal
passed as template tuple parameter
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@kyllingen.net
--- Comment #0 from Lars T. Kyllingstad 2010-06-21
11:40:00 PDT ---
In the code below, the variable i is never increased above x+1. It seems the
declaration inside the loop somehow overwrites i. (Note that the writeln() is
only for demonstration purposes and has nothing to do with the bug.)
import std.stdio;
void run(fun...)()
{
fun[0]();
}
void main()
{
run!(delegate void()
{
for (int i = 0; i < 100_000; i++)
{
writeln(i);
auto x = 0; // i never exceeds 1
}
})();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4357] Stack allocation for small scope dynamic arrays
http://d.puremagic.com/issues/show_bug.cgi?id=4357 --- Comment #2 from bearophile_h...@eml.cc 2010-06-21 11:23:19 PDT --- Sorry, I didn't know that. I have thought that the removal of the scope attribute was only for class instances. Even if the scope attribute can't be used on dynamic arrays, the last point I have expressed applies still: if the compiler is able to perform escape analysis (LLVM has some of such capability) and it can statically verify a dynamic array never escapes, then if a runtime test shows such dynamic arrays is small it can be allocated on the stack. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4349] Deprecate automatic case fallthrough
http://d.puremagic.com/issues/show_bug.cgi?id=4349 --- Comment #3 from bearophile_h...@eml.cc 2010-06-21 11:19:01 PDT --- Answer to Comment 2: I agree that it's easy for people to understand that there's a requirement to insert a break or similar. This is what I have written in the Description. But this was not the point of my Comment 1. In Comment 1 I was talking about the *exception* to that easy rule. What I was trying to express is that I don't like such exception to the rule. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1824] Object not const correct
http://d.puremagic.com/issues/show_bug.cgi?id=1824 Lars T. Kyllingstad changed: What|Removed |Added CC||bugzi...@kyllingen.net Component|Phobos |druntime AssignedTo|nob...@puremagic.com|s...@invisibleduck.org --- Comment #8 from Lars T. Kyllingstad 2010-06-21 10:44:32 PDT --- As of DMD 2.020, this is a druntime issue, not a Phobos one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4358] New: Potential Memory Leaks in std.file.read() ?
http://d.puremagic.com/issues/show_bug.cgi?id=4358
Summary: Potential Memory Leaks in std.file.read() ?
Product: D
Version: D1
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: m...@vermi.fr
--- Comment #0 from Vermi 2010-06-21 10:13:49 PDT ---
Created an attachment (id=668)
Source file showing problem in memory managment
Hi,
it looks like the Garbage Collector don't free the memory used by
std.file.read().
Here a simple example :
[code]
import std.file;
import std.gc;
void main()
{
for (int i=0; i<4096; i++)
{
void[] buffer = std.file.read("C:\\windows\\System32\\imageres.dll");
std.gc.fullCollect();
}
}
[/code]
With this code I get a memory usage of ~200 MB. Now, simply change it with :
[code]
import std.file;
import std.gc;
void main()
{
for (int i=0; i<4096; i++)
{
void[] buffer = std.file.read("C:\\windows\\System32\\imageres.dll");
std.gc.fullCollect();
delete buffer;
}
}
[/code]
The memory usage is now about 20 MB. (the size of the file). It poses me a big
problem with a program I'm writing, mermoy usage is rising until ~600 MB...
Must I add delete everywhere in my code ?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4349] Deprecate automatic case fallthrough
http://d.puremagic.com/issues/show_bug.cgi?id=4349 Andrei Alexandrescu changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #2 from Andrei Alexandrescu 2010-06-21 06:30:56 PDT --- This is all unnecessary aggravation. I don't think it's complicated for anyone to understand that there's a requirement to insert a "break;" (or another control flow statement) in places where a "break;" should be inserted anyway. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4357] Stack allocation for small scope dynamic arrays
http://d.puremagic.com/issues/show_bug.cgi?id=4357 nfx...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||nfx...@gmail.com Resolution||WONTFIX --- Comment #1 from nfx...@gmail.com 2010-06-21 05:03:49 PDT --- Andrei said this use of scope is gone. Sorry pal, WONTFIX *bamm* -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4357] New: Stack allocation for small scope dynamic arrays
http://d.puremagic.com/issues/show_bug.cgi?id=4357
Summary: Stack allocation for small scope dynamic arrays
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 2010-06-21 04:52:09 PDT ---
Dynamic arrays are used very often in D, much more often than malloc-allocated
arrays in C programs.
A scope dynamic array lives only inside the function it's allocated. So with
this program:
int[] foo(int n) {
scope arr = new int[n];
return arr;
}
void main() {}
DMD v2.047 generates this error:
test.d(3): Error: escaping reference to scope local arr
So the compiler can add an inlined runtime test: if the amount of memory
necessary to allocate 'arr' is "small" (like few hundred bytes) (or better if
it is small compared to the free space currently available on the stack), then
the memory for 'arr' can be allocated on the stack instead of the heap, with an
alloca. This can improve performance a little if foo() is called many times.
Compared to C programs (or D programs written in C-like style), this
optimization can make the D idiom of using dynamic arrays often less costly,
and avoids most of the need of the Variable Length Arrays of C99.
This enhancement request is marked as relative to the DMD component (instead of
being just a runtime thing) because the test and the optional stack allocation
need to be inlined.
A D compiler can perform the same optimization on dynamic array allocation even
if the 'scope' attribute is missing if it is able to perform some escape
analysis and it is able to verify that 'arr' never escapes foo().
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4349] Deprecate automatic case fallthrough
http://d.puremagic.com/issues/show_bug.cgi?id=4349
--- Comment #1 from bearophile_h...@eml.cc 2010-06-21 03:17:29 PDT ---
Sean Kelly and Michel Fortin have shown some code examples.
This D code:
switch (x) {
case 1: case 2: case 3: case 4:
doSomething();
break;
default:
whatever();
}
With the new proposal can be translated like this (this is already D syntax):
switch (x) {
case 1, 2, 3, 4:
doSomething();
break;
default:
whatever();
break;
}
C/C++ programmers that will want to use D will have to learn the new rule that
says: "In D there is no automatic case fallthrough". But allowing the
fallthrough when there are no statements after the label is a special case to
the general rule that they have to learn: ", unless there are no statements
inside the case.".
Special cases are bad in a programming language, they make manuals longer,
require more time and energy for the programmer to learn them, make the
compiler more complex and more buggy, and often slow down the programming even
whey they were created to give a handy special case.
-
This D code gives a little more problems:
switch (x) {
case 1: .. case 10:
case 22: .. case 32:
case 52, 64:
doSomething();
break;
default:
whatever();
}
With the new proposal it can be translated like this (this is new syntax), that
considers a closed range of values one of the possible items of the list of
cases:
switch (x) {
case 1: .. case 10,
case 22: .. case 32,
52, 64:
doSomething();
break;
default:
whatever();
}
Or just like this (this is normal D syntax):
switch (x) {
case 1: .. case 10: goto case;
case 22: .. case 32: goto case;
case 52, 64:
doSomething();
break;
default:
whatever();
}
This shorter syntax (that uses a single 'case' statement) is now not available:
switch (x) {
case 1 ... 10, 22 ... 32, 52, 64:
doSomething();
break;
default:
whatever();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4356] Copy constructor not called under extremely mysterious circumstances
http://d.puremagic.com/issues/show_bug.cgi?id=4356
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #1 from Walter Bright 2010-06-21
02:13:46 PDT ---
Simpler test case:
import std.c.stdio;
struct A
{
int m;
this(this)
{
printf("this(this) %p\n", &this);
}
~this()
{
printf("~this() %p\n", &this);
}
A copy()
{
A another = this;
return another;
}
}
void main()
{
A a;
A b = a.copy();
printf("a: %p, b: %p\n", &a, &b);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
