Re: [Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.
On 11/21/2010 08:20 PM, Sean Kelly wrote: d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=2834 Max Samukhasamu...@voliacable.com changed: What|Removed |Added CC| |samu...@voliacable.com --- Comment #8 from Max Samukhasamu...@voliacable.com 2010-11-18 03:39:17 PST --- So what is the verdict? Should we simply specify that struct destructors are not automatically called except in RAII and remove the struct-in-class special case? BTW, there are other problems (serious IMO): auto ss = new S[10]; ss.length = 5; delete ss; Destructors are not called on the last 5 elements. auto ss = new S[10]; ss ~= ss; delete ss; We have a nasty problem when destructors are called on the appended elements because postblits was not run for them during append. etc Essentially, operations on arrays of structs with postblits/dtors defined are currently unusable. I think this is unavoidable. Consider: auto a = new T[5]; auto b = a[4..5]; a.length = 4; We can't safely destroy a[4] because it's aliased. Also, since there's no concept of an owner reference vs an alias, modifying the length of b could screw up a as well. For this and other reasons I'm inclined to withdraw this issue, and declare that since structs are value types they won't be automatically destroyed when collected by the GC or when held in arrays. I agree that correct automatic struct destruction is impossible without significant changes to arrays/slices/GC.
[Issue 3681] ICE(go.c): when function takes too long to optimize, only with -O.
http://d.puremagic.com/issues/show_bug.cgi?id=3681
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Don clugd...@yahoo.com.au 2010-11-22 00:50:30 PST ---
CAUSE: This section of the optimiser can only remove one comma expression per
pass. So, the limit should be set based on the depth of comma expressions.
I don't know what the minimum iteration limit should be (the number of passes
for performing all other optimisations) -- when setting it to 10, as in the
code below, the test suite passes; a level of 5 is too low.
Note that the total limit used to be set to 80, before it was increased to 200.
I am certain that the 80 was caused by comma expressions. Need to run this
through the DMC test suite, to see what the minimum iteration limit should be.
--
PATCH: Add this function to go.c. Actually it needs to used in the fix for bug
4379, as well. So maybe it should go into another file, or appear in a header
file.
/*
Return the maximum nesting of comma expressions in the elem tree.
For example, (((a, b) + c),d) * (e,f) has comma depth 2.
*/
int commaDepth(elem *e)
{
if ( EBIN(e))
{
int depth = (e-Eoper == OPcomma) ? 1 : 0;
return depth + commaDepth(e-E1) + commaDepth(e-E2);
}
else if (EUNA(e))
return commaDepth(e-E1);
return 0;
}
Then, go.c, optfunc(), around line 230:
if (localgot)
{ // Initialize with:
// localgot = OPgot;
elem *e = el_long(TYnptr, 0);
e-Eoper = OPgot;
e = el_bin(OPeq, TYnptr, el_var(localgot), e);
startblock-Belem = el_combine(e, startblock-Belem);
}
+// Each pass through the loop can reduce only one level of comma
expression.
+// The infinite loop check needs to take this into account.
+int iterationLimit = 10;
+for (b = startblock; b; b = b-Bnext)
+{
+if (!b-Belem)
+continue;
+int d = commaDepth(b-Belem);
+if (d iterationLimit)
+iterationLimit = d;
+}
// Some functions can take enormous amounts of time to optimize.
// We try to put a lid on it.
starttime = clock();
do
{
//printf(iter = %d\n, iter);
#if TX86
//assert(++iter 80); /* infinite loop check */
-assert(++iter 200); /* infinite loop
+assert(++iter iterationLimit); /* infinite loop check
*/
#else
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4379] ICE(blockopt.c): foreach over huge tuple, only with -O
http://d.puremagic.com/issues/show_bug.cgi?id=4379
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Don clugd...@yahoo.com.au 2010-11-22 01:26:45 PST ---
This turns out to be very simple. When merging blocks together, we need to
allow one pass per block, since it only merges one block per pass.
In the test case, there are more than 200 blocks, and they all get merged into
one.
PATCH:
blockopt.c, blockopt(), line 595
void blockopt(int iter)
{ block *b;
int count;
if (OPTIMIZER)
{
+int iterationLimit = 200;
+if (iterationLimit numblks)
+iterationLimit = numblks;
count = 0;
do
{
and line 622
do
{
compdfo(); /* compute depth first order (DFO) */
elimblks(); /* remove blocks not in DFO */
-assert(count 200);
+assert(count iterationLimit);
count++;
} while (mergeblks()); /* merge together blocks */
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4504] ICE(toir.c) using std.algorithm.count with recursive nested function and -inline.
http://d.puremagic.com/issues/show_bug.cgi?id=4504
--- Comment #5 from Don clugd...@yahoo.com.au 2010-11-22 02:02:04 PST ---
Reduced test case, from the duplicate bug 4784.
---
struct A( alias P ) {
static void a() {
void aa() { P(); }
}
}
template B( alias P ) {
void b() { A!P a; }
}
struct C( alias P ) {
void c() { B!P.b(); }
}
void main() {
void bar() {}
C!bar c;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4784] ICE(toir.c) with count()
http://d.puremagic.com/issues/show_bug.cgi?id=4784 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Don clugd...@yahoo.com.au 2010-11-22 02:12:16 PST --- *** This issue has been marked as a duplicate of issue 4504 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4504] ICE(toir.c) using std.algorithm.count with recursive nested function passed by alias
http://d.puremagic.com/issues/show_bug.cgi?id=4504 Don clugd...@yahoo.com.au changed: What|Removed |Added Summary|ICE(toir.c) using |ICE(toir.c) using |std.algorithm.count with|std.algorithm.count with |recursive nested function |recursive nested function |and -inline.|passed by alias --- Comment #6 from Don clugd...@yahoo.com.au 2010-11-22 02:07:10 PST --- The reduced case shows it doesn't require -inline. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4504] ICE(toir.c) using std.algorithm.count with recursive nested function passed by alias
http://d.puremagic.com/issues/show_bug.cgi?id=4504 --- Comment #7 from Don clugd...@yahoo.com.au 2010-11-22 02:12:16 PST --- *** Issue 4784 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 5230] ICE(tocsym.c) overriding a method that has an out contract
http://d.puremagic.com/issues/show_bug.cgi?id=5230
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Don clugd...@yahoo.com.au 2010-11-22 06:44:54 PST ---
Exactly the same fix for bug 3602 works here, applied to fensure instead of
frequire:
PATCH: func.c, mergeFensure(), line 1728
for (int i = 0; i foverrides.dim; i++)
{
FuncDeclaration *fdv = (FuncDeclaration *)foverrides.data[i];
+/* The semantic pass on the contracts of the overridden functions must
+ * be completed before code generation occurs (bug 3602 and 5230).
+ */
+if (fdv-fdensure fdv-fdensure-semanticRun != PASSsemantic3done)
+{
+assert(fdv-scope);
+fdv-semantic3(fdv-scope);
+}
sf = fdv-mergeFensure(sf);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5253] Regression (2.050): in contracts are not allowed in overriden methods.
http://d.puremagic.com/issues/show_bug.cgi?id=5253 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #2 from Don clugd...@yahoo.com.au 2010-11-22 07:01:01 PST --- *** This issue has been marked as a duplicate of issue 5145 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5145] Regression(2.050, 1.065) override error with forward ref of superclass
http://d.puremagic.com/issues/show_bug.cgi?id=5145 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||bary...@smp.if.uj.edu.pl --- Comment #3 from Don clugd...@yahoo.com.au 2010-11-22 07:01:01 PST --- *** Issue 5253 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 5251] Const C file
http://d.puremagic.com/issues/show_bug.cgi?id=5251 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Resolution||INVALID --- Comment #1 from Steven Schveighoffer schvei...@yahoo.com 2010-11-22 08:58:52 PST --- (In reply to comment #0) I think this program is supposed to work, because fprintf() and fclose() don't modify 'fout': Yes they do. fprintf and fclose deal with a memory-allocated buffer that will be used to optimize I/O throughput. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5251] Const C file
http://d.puremagic.com/issues/show_bug.cgi?id=5251 --- Comment #2 from bearophile_h...@eml.cc 2010-11-22 09:34:42 PST --- (In reply to comment #1) Yes they do. fprintf and fclose deal with a memory-allocated buffer that will be used to optimize I/O throughput. If this bug report is invalid then thank you for closing it. I am not expert enough on this. But I don't understand what you have said. Even if fprintf and fclose deal with a memory-allocated buffer, do they modify the value of 'fout'? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5240] Faster std.random.uniform() for [0.0, 1.0) range
http://d.puremagic.com/issues/show_bug.cgi?id=5240 --- Comment #4 from bearophile_h...@eml.cc 2010-11-22 09:44:33 PST --- (In reply to comment #3) I am probably missing something, but what is wrong with uniform!(0,1) ? Then you can add optimizations for all the special cases you want. Currently uniform() uses run-time arguments, not template ones. -- See also: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=122634 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5251] Const C file
http://d.puremagic.com/issues/show_bug.cgi?id=5251
--- Comment #3 from Steven Schveighoffer schvei...@yahoo.com 2010-11-22
10:11:55 PST ---
const is transitive, so if you imagine a FILE having this structure:
struct FILE
{
int fd;
ubyte[] buffer;
}
Now, if FILE is const, then buffer is const(ubyte[]), so how does fprintf write
to that buffer?
What you are looking for is head-const (the variable cannot change, but
everything it points to can), which has some good uses, but does not exist in
D.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5251] Const C file
http://d.puremagic.com/issues/show_bug.cgi?id=5251
--- Comment #4 from bearophile_h...@eml.cc 2010-11-22 10:16:12 PST ---
(In reply to comment #3)
const is transitive, so if you imagine a FILE having this structure:
struct FILE
{
int fd;
ubyte[] buffer;
}
Now, if FILE is const, then buffer is const(ubyte[]), so how does fprintf
write
to that buffer?
What you are looking for is head-const (the variable cannot change, but
everything it points to can), which has some good uses, but does not exist in
D.
I understand, you are right, thank you.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5251] Const C file
http://d.puremagic.com/issues/show_bug.cgi?id=5251 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #5 from nfx...@gmail.com 2010-11-22 10:30:04 PST --- (In reply to comment #3) What you are looking for is head-const (the variable cannot change, but everything it points to can), which has some good uses, but does not exist in D. It exists to some degree in D1: final int[] a = [1,2]; a[0] = 1; //works a = [5,6]; //Error: cannot modify final variable 'a' Apparently this was disabled in D2. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5257] New: std.algorithm.count works incorrectly with UTF8 and UTF16 strings
http://d.puremagic.com/issues/show_bug.cgi?id=5257
Summary: std.algorithm.count works incorrectly with UTF8 and
UTF16 strings
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: and...@metalanguage.com
--- Comment #0 from Andrei Alexandrescu and...@metalanguage.com 2010-11-22
10:54:01 PST ---
import std.stdio;
import std.algorithm;
void main() {
writeln(count!(true)(日本語)); // Three characters.
}
The code prints 9 but should print 3.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5257] std.algorithm.count works incorrectly with UTF8 and UTF16 strings
http://d.puremagic.com/issues/show_bug.cgi?id=5257 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|nob...@puremagic.com|and...@metalanguage.com --- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2010-11-22 10:54:48 PST --- Submitted on behalf of Rainer Deyke. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3827] automatic joining of adjacent strings is bad
http://d.puremagic.com/issues/show_bug.cgi?id=3827 --- Comment #24 from bearophile_h...@eml.cc 2010-11-22 12:01:40 PST --- A recent note by Walter: Andrei's right. This is not about making it right-associative. It is about defining in the language that: ((a ~ b) ~ c) is guaranteed to produce the same result as: (a ~ (b ~ c)) Unfortunately, the language cannot make such a guarantee in the face of operator overloading. But it can do it for cases where operator overloading is not in play. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5240] Faster std.random.uniform() for [0.0, 1.0) range
http://d.puremagic.com/issues/show_bug.cgi?id=5240 --- Comment #6 from bearophile_h...@eml.cc 2010-11-22 12:05:44 PST --- (In reply to comment #5) I was commenting on the suggested name uniform01. Templating the function seemed obvious to me and I was also surprised you didn't suggest doing that so I thought I was missing something there. I don't like the idea of a templated ranged uniform. In most cases is not what I need or what's better. As for speed, as tn mentioned on the newsgroup, subnormal numbers considerately slow down calculations. It's in the link of Comment 4 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5257] std.algorithm.count works incorrectly with UTF8 and UTF16 strings
http://d.puremagic.com/issues/show_bug.cgi?id=5257 jakobov...@gmail.com changed: What|Removed |Added CC||jakobov...@gmail.com --- Comment #2 from jakobov...@gmail.com 2010-11-22 12:28:48 PST --- This is almost entirely off-topic, but I don't think such a tiny change deserves its own issue... sorry if I should have :( When this gets fixed, count() will be useful as a generic way to count the amount of code points in a UTF encoded string. But I don't think the interface is very pretty for this simple use case. As a completely non-breaking change, how about changing: size_t count(alias pred, Range)(Range r) if (isInputRange!(Range)) to: size_t count(alias pred = true, Range)(Range r) if (isInputRange!(Range)) So one could simply do count(日本語)? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5258] New: [CTFE] Stack overflow with struct by ref
http://d.puremagic.com/issues/show_bug.cgi?id=5258
Summary: [CTFE] Stack overflow with struct by ref
Product: D
Version: D2
Platform: x86
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 2010-11-22 17:09:12 PST ---
This D2 program generates a Stack Overflow with DMD 2.050 despite the stack
dept is very small:
struct Foo { int x; }
void bar(int n, ref Foo f) {
if (n)
bar(n - 1, f);
else
f.x++;
}
int spam() {
bar(1, Foo());
return 0;
}
enum _ = spam();
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5259] New: Download link from homepage points to older version
http://d.puremagic.com/issues/show_bug.cgi?id=5259 Summary: Download link from homepage points to older version Product: D Version: D2 Platform: Other OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: and...@metalanguage.com --- Comment #0 from Andrei Alexandrescu and...@metalanguage.com 2010-11-22 22:13:14 PST --- Download now off the D section on digitalmars.com downloads 2.049, but the latest version is 2.050. I use this opportunity to reemphasize the necessity of automating the essential amenities and flows on the website. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
