[Issue 3342] TLS on dynamically loaded DLLs fails on Windows earlier than Vista
http://d.puremagic.com/issues/show_bug.cgi?id=3342 --- Comment #4 from Rainer Schuetze r.sagita...@gmx.de 2010-03-10 01:32:28 PST --- There is a detection whether _tls_index is set and the tls-data-array contains a valid pointer (thinking about it the latter might be flawed), so this should cover any situation where the OS did not setup TLS correctly (when loaded at process init time, TLS is correct on XP, too). Do you think, that an explicite version check is better? What about applications that are configured to pretend running under a different windows version? As much as I can see, the referenced code contains two things not in the patch: - it keeps track of used tls-indexes in a bitmap, but XP does not have this. That's why the patch prevents unloading of the DLL. - it uses ExReleaseRundownProtection before accessing some TEB data, but this seems to be an (undocumented) kernel function, and I think we should be safe with our operations as the nt-loader holds a lock that disallows reentrence into DllMain -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2671] Circular imports and static constructors in templates
http://d.puremagic.com/issues/show_bug.cgi?id=2671
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||bugzi...@digitalmars.com
Resolution||WORKSFORME
--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2010-03-10
03:12:13 PST ---
I cannot reproduce this on either D1.057 or D2.041.
-- a.d ---
module a;
template Foo(int i)
{
static this()
{
}
}
void main() { }
- b.d
module b;
import a;
alias Foo!(1) foo;
- c.d
module c;
import a;
alias Foo!(2) foo;
--
dmd -c a
dmd -c b
dmd -c c
dmd a.obj b.obj c.obj
a
-- this works too
dmd a b c
a
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3921] New: Compile time evaluation requirements not well-specified
http://d.puremagic.com/issues/show_bug.cgi?id=3921 Summary: Compile time evaluation requirements not well-specified Product: D Version: 2.041 Platform: All URL: file:///home/jlquinn/dmd2/html/d/function.html OS/Version: All Status: NEW Keywords: spec Severity: major Priority: P2 Component: www.digitalmars.com AssignedTo: nob...@puremagic.com ReportedBy: jlqu...@optonline.net --- Comment #0 from Jerry Quinn jlqu...@optonline.net 2010-03-10 04:44:19 PST --- The language of the spec does not clearly state what a compile must be able to evaluate at compile time. Through example, clearly constant folding must be done, to support mixins as shown in various examples, but the full rules of what the D language requires to be done at compile time is not given. Similarly, CTFE states that the compiler can execute functions at compile time if they meet certain constraints. However, it doesn't clearly state whether the D language requires that these functions be executed at compile time. Other writing I've seen suggests that CTFE is an optimization, not a language requirement. What exactly is required of any D compiler? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3922] New: Wrong error message with return in void function
http://d.puremagic.com/issues/show_bug.cgi?id=3922
Summary: Wrong error message with return in void function
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-03-10 05:02:48 PST ---
This is a wrong program:
void foo(int x) {
return x;
}
void main() {}
Currently dmd2 generates a bad error message:
temp.d(2): Error: var has no effect in expression (x)
A much better error message can be:
temp.d(2): Error: return can't be used in a void function.
Bad error messages like this one do waste my programming time.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3923] New: std.algorithm.find is too much hard to understand
http://d.puremagic.com/issues/show_bug.cgi?id=3923 Summary: std.algorithm.find is too much hard to understand Product: D Version: 2.041 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-03-10 06:23:10 PST --- The find() of std.algorithm is too much hard to understand. I can't understand how to use it and what it returns. It's even hard to understand this in the docs page: FindResult!(Range,Ranges) find(alias pred = a == b, Range, Ranges...)(Range haystack, Ranges needles); struct BoyerMooreFinder(alias pred,Range); BoyerMooreFinder!(binaryFun!(pred),Range) boyerMooreFinder(alias pred = a == b, Range)(Range needle); Such functions must be simple enough for normal people to use. If you need more than 10 minutes to understand how to use something as simple as a find, then the library API is badly designed. It's not a limit of my brain, it's a problem in the library design. If I need to know that the substring foo is present in abfoobar in Python I write: foo in abfoobar This covers 85%+ of the cases in normal programs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3924] New: nothrow ignored in some situations
http://d.puremagic.com/issues/show_bug.cgi?id=3924
Summary: nothrow ignored in some situations
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-03-10 06:53:26 PST ---
The following programs compile and raise exceptions even if the
functions/delegates are marked as nothrow:
--
void main() {
nothrow void delegate() c = { throw new Exception(); };
c();
}
--
nothrow auto foo() {
throw new Exception();
}
void main() {
foo();
}
--
nothrow auto foo() {
auto c = { throw new Exception(); };
c();
}
void main() {
foo();
}
-
While this code that looks correct doesn't compile:
pure void foo(pure nothrow void delegate(int) callable) {
callable(5);
}
void main() {
pure nothrow void bar(int x) {}
foo(bar);
}
With the first error:
test1.d(1): basic type expected, not pure
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3925] New: Missed escaping reference of a local variable
http://d.puremagic.com/issues/show_bug.cgi?id=3925
Summary: Missed escaping reference of a local variable
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-03-10 07:38:56 PST ---
This is a wrong program, and the compiler shows the right error messages, of x
and y escaping:
ref int foo(int x) {
return x;
}
int* baz() {
int y;
return y;
}
void main() {}
---
But in the following case the compiler doesn't show an error:
ref int foo(ref int x) {
return x;
}
ref int bar() {
int x;
return foo(x); // escaping reference of x
}
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3926] New: opCast(bool) in classes is bug-prone
http://d.puremagic.com/issues/show_bug.cgi?id=3926
Summary: opCast(bool) in classes is bug-prone
Product: D
Version: 2.041
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-03-10 08:01:15 PST ---
A opCast(bool) operator present in struct is called automatically in a if(x),
but the same is not true if x is a class.
So for example if you modify your code changing a struct into a class, other
parts of the program will silently stop working (it usually return true if the
class reference is not null). This is a problem, because it's bug-prone.
This shows the situation:
import std.stdio: writeln;
struct FooStruct {
int x;
T opCast(T:bool)() {
return this.x != 0;
}
}
class FooClass {
int x;
this(int xx) { this.x = xx; }
static FooClass opCall(int xx) { return new FooClass(xx); }
T opCast(T:bool)() {
return this.x != 0;
}
}
void main() {
enum int N = 0;
auto fstruct = FooStruct(N);
if (fstruct)
writeln(fstruct true);
else
writeln(fstruct false); // fstruct false
auto fclass = FooClass(N);
if (fclass)
writeln(fclass true); // fclass true
else
writeln(fclass false);
if (cast(bool)fclass)
writeln(fclass true);
else
writeln(fclass false); // fclass false
}
A possible simple solution is to selectively disallow opCast(bool) for classes.
So an hypothetical conversion of a struct to a class raises a compile time
error that helps avoid bugs. But this makes it impossible to have cast(bool) on
classes. I don't know how often a cast(bool) can be useful in a class (probably
not often).
Another possible solution is to keep allowing cast(bool) in classes, but have
if(fclass) call opCast(bool) for classes too, avoiding the asymmetry between
structs and classes. But this requires to write if(fclass is null) to test the
value of the object reference.
This problem has to be faced soon, because later it will become impossible to
fix.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1997] Better type inference for templated types
http://d.puremagic.com/issues/show_bug.cgi?id=1997
Jesse Phillips jesse.k.phillip...@gmail.com changed:
What|Removed |Added
CC||jesse.k.phillip...@gmail.co
||m
Version|unspecified |2.041
--- Comment #1 from Jesse Phillips jesse.k.phillip...@gmail.com 2010-03-10
08:46:35 PST ---
DMD includes private methods when it tries to match for type inference even
though the private function is not available.
.\test.d(10): Error: template bar.Bar(T) does not match any function template
declaration
.\test.d(10): Error: template bar.Bar(T) cannot deduce template function from
argument types !()(void delegate())
--
module bar;
import foo;
void Bar(T)(void delegate(T) call) {
}
void main() {
auto foo = new Foo();
Bar(foo.fish);
}
--
module foo;
class Foo {
private void fish() {
}
public void fish(string color) {
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3925] Missed escaping reference of a local variable
http://d.puremagic.com/issues/show_bug.cgi?id=3925
--- Comment #1 from bearophile_h...@eml.cc 2010-03-10 10:08:04 PST ---
This was the original code by Michel Fortin:
@safe ref int foo(ref int a) {
return a;
}
@safe ref int bar() {
int a;
return foo(a);
}
Norbert Nemec comments:
I would say the possibility of a bug makes this code unsafe by definition. Ref
returns must be considered unsafe by default, unless the compiler can know for
sure that the object will exist beyond the lifetime of the function.
So I think Norbert Nemec idea is: while the normal compiler error messages
assume correctness and need a demonstration of unsafety to be shown, @safe can
do the opposite assuming unsafety and requiring a demonstration of safety.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3927] New: array.length++; is an error
http://d.puremagic.com/issues/show_bug.cgi?id=3927
Summary: array.length++; is an error
Product: D
Version: 2.041
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-03-10 10:12:01 PST ---
With the following D2 program:
void main() {
int[] array;
array.length++;
array.length--;
}
The compiler shows the following errors, is this correct?
test1.d(3): Error: a.length is not an lvalue
test1.d(4): Error: a.length is not an lvalue
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3925] Missed escaping reference of a local variable
http://d.puremagic.com/issues/show_bug.cgi?id=3925
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #2 from Don clugd...@yahoo.com.au 2010-03-10 11:12:03 PST ---
(In reply to comment #1)
This was the original code by Michel Fortin:
@safe ref int foo(ref int a) {
return a;
}
@safe ref int bar() {
int a;
return foo(a);
}
Norbert Nemec comments:
I would say the possibility of a bug makes this code unsafe by definition.
Ref returns must be considered unsafe by default, unless the compiler can
know for sure that the object will exist beyond the lifetime of the
function.
So I think Norbert Nemec idea is: while the normal compiler error messages
assume correctness and need a demonstration of unsafety to be shown, @safe can
do the opposite assuming unsafety and requiring a demonstration of safety.
I've just been dealing with ref returns in my recent CTFE patch. But I don't
think it's very complicated.
As far as I can tell, ref returns are only a problem if a local variable is
passed as a ref parameter, or if it is a member function of a local struct.
If either of those is true, it should be considered to potentially be a return
of a local variable.
I don't think there's any problem with foo, but bar should generate an error.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3921] Compile time evaluation requirements not well-specified
http://d.puremagic.com/issues/show_bug.cgi?id=3921 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2010-03-10 11:21:59 PST --- Quoting the spec: In order to be executed at compile time, the function must appear in a context where it must be so executed Note the word MUST. I don't see anything in the spec to indicate that it is optional. It's pretty simple actually -- if the compiler *needs* a constant, and it sees an expression, it attempts to constant-fold that expression. If the expression contains a function call, CTFE will be used. CTFE is not used in any other context - it never happens unless requested. Other writing I've seen suggests that CTFE is an optimization, not a language requirement. Can you remember where you saw that writing, or got that impression? If it's anywhere public, we need to get rid of it, since it is not correct. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3914] Struct as argument that fits in register has member accessed wrong
http://d.puremagic.com/issues/show_bug.cgi?id=3914 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Severity|normal |critical -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3835] ref foreach does not work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=3835 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||rejects-valid Summary|[CTFE] Fragile CTFE |ref foreach does not work ||in CTFE --- Comment #8 from Don clugd...@yahoo.com.au 2010-03-10 11:24:04 PST --- Bug 2411 is NOT the same as this. (2411 does not involve CTFE). Changing title. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3925] Missed escaping reference of a local variable
http://d.puremagic.com/issues/show_bug.cgi?id=3925
Michel Fortin michel.for...@michelf.com changed:
What|Removed |Added
CC||michel.for...@michelf.com
--- Comment #3 from Michel Fortin michel.for...@michelf.com 2010-03-10
15:04:05 EST ---
(In reply to comment #2)
I've just been dealing with ref returns in my recent CTFE patch. But I don't
think it's very complicated.
As far as I can tell, ref returns are only a problem if a local variable is
passed as a ref parameter, or if it is a member function of a local struct.
If either of those is true, it should be considered to potentially be a return
of a local variable.
I don't think there's any problem with foo, but bar should generate an error.
This seems fair. There is a similar problem with delegates:
@safe
void delegate() foo(ref int a) {
return { writeln(a); };
}
@safe
void delegate() bar() {
int a;
return foo(a); // leaking reference to a beyound bar's scope
}
It could be solved in the same way.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3928] New: Comparing imaginaries with reals produces results that are inconsistent
http://d.puremagic.com/issues/show_bug.cgi?id=3928
Summary: Comparing imaginaries with reals produces results that
are inconsistent
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: crimson.ma...@gmail.com
--- Comment #0 from Aldo Nunez crimson.ma...@gmail.com 2010-03-10 12:04:36
PST ---
Comparing an imaginary number like an ifloat with a real one like a float:
1. Has results that differ at compile time and runtime.
2. At runtime is done in the wrong order.
3. Doesn't seem to be very meaningful, given that you can't compare complex
numbers.
With respect to each issue above, here are some more details.
1. Different results at runtime and compile time.
At compile time, if the left is imaginary, then we take the imaginary part of
the right side and compare the two. If the left side is real, then we take the
real part of the right side and compare.
All of this is as seen in constfold.c.
At runtime, we turn both sides into complex numbers by making a missing part
zero. Then, we compare the imaginary parts, and if they're equal, compare the
real parts.
2. Wrong order at runtime.
In the runtime comparison described in #1 what's actually compared is right to
left instead of left to right. If my program has a b, then b a is
checked.
3. Meaning?
Comparisons where at least one side is a complex number are not allowed in D.
As such, is it meaningful to allow the comparisons described here, given that
such numbers are treated as complex numbers and compared?
Note, all of this is strictly where one side of a compare expression is an
imaginary number and the other is a real number.
Here's a sample program:
import std.stdio;
void main()
{
cfloatcf1 = 1 + 2i;
cfloatcf2 = 3 + 4i;
ifloatif2 = 1i;
floatf2 = 3;
ifloatif3 = 4i;
floatf3 = 2;
ifloat if4 = 5i;
float f4 = 5;
writeln( --- --- );
writeln( if2 f2 );
writeln( f2 if2 );
writeln( if3 f3 );
writeln( f3 if3 );
writeln( if4 f4 );
writeln( f4 if4 );
writeln( 1i 3 );
writeln( 3 1i );
writeln( 4i 2 );
writeln( 2 4i );
writeln( 5i 5 );
writeln( 5 5i );
writeln( --- == --- );
writeln( if2 == f2 );
writeln( f2 == if2 );
writeln( if3 == f3 );
writeln( f3 == if3 );
writeln( if4 == f4 );
writeln( f4 == if4 );
writeln( 1i == 3 );
writeln( 3 == 1i );
writeln( 4i == 2 );
writeln( 2 == 4i );
writeln( 5i == 5 );
writeln( 5 == 5i );
writeln( --- --- );
writeln( if2 f2 );
writeln( f2 if2 );
writeln( if3 f3 );
writeln( f3 if3 );
writeln( if4 f4 );
writeln( f4 if4 );
writeln( 1i 3 );
writeln( 3 1i );
writeln( 4i 2 );
writeln( 2 4i );
writeln( 5i 5 );
writeln( 5 5i );
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3826] init of fixed sized arrays
http://d.puremagic.com/issues/show_bug.cgi?id=3826
Philippe Sigaud philippe.sig...@gmail.com changed:
What|Removed |Added
CC||philippe.sig...@gmail.com
--- Comment #1 from Philippe Sigaud philippe.sig...@gmail.com 2010-03-10
21:58:34 CET ---
It's even more general than that: (T[n]).init is T.init. It's not even the
correct type!
That seems wrong to me. It should be a T[n] filled with T.init.
int[2] i2; double[3] d2; char[1] c2; string[0] s2;
writeln(typeof(i2).stringof, , typeof(typeof(i2).init).stringof);// int[2]
int
writeln(typeof(d2).stringof, , typeof(typeof(d2).init).stringof);//
double[3] double
void f(int a) {}
void g(int[2] a) {}
auto i3 = (int[2]).init;
f(i3); // Works. i3 is of type int.
g(i3); // Does not work. i3 is of type int.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3912] pure static nested functions are not recognized as pure
http://d.puremagic.com/issues/show_bug.cgi?id=3912
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Don clugd...@yahoo.com.au 2010-03-10 13:48:03 PST ---
This was a mistake in my patch for bug 2804 (one of my first ever patches).
I had only considered one level of nesting.
I've also changed the error message so that it names the pure function, not the
nested impure one.
There's also some error messages with spurious newlines in them.
Here's a test case which should fail:
---
void f() pure
{ void g()
{
void h() pure
{
void i() { }
void j() { i(); g(); }
}
}
}
--
PATCH against DMD2.041. Expression::checkPurity(), around line 1280.
Index: expression.c
===
--- expression.c(revision 413)
+++ expression.c(working copy)
@@ -1296,17 +1296,31 @@
* i() can call h() and g() but not f()
*/
FuncDeclaration *outerfunc = sc-func;
-while (outerfunc-toParent2()
outerfunc-toParent2()-isFuncDeclaration())
+// Find the closest pure parent of the calling function
+while (outerfunc-toParent2() !outerfunc-isPure()
+outerfunc-toParent2()-isFuncDeclaration() )
{
outerfunc = outerfunc-toParent2()-isFuncDeclaration();
}
-if (outerfunc-isPure() !sc-intypeof (!f-isNested()
!f-isPure()))
-error(pure function '%s' cannot call impure function '%s'\n,
-sc-func-toChars(), f-toChars());
+// Find the closest pure parent of the called function
+FuncDeclaration *calledparent = f;
+while (calledparent-toParent2() !calledparent-isPure()
+ calledparent-toParent2()-isFuncDeclaration() )
+{
+calledparent = calledparent-toParent2()-isFuncDeclaration();
+}
+// If the caller has a pure parent, then either the called func must be
pure,
+// OR, they must have the same pure parent.
+if (outerfunc-isPure() !sc-intypeof
+!(f-isPure() || (calledparent == outerfunc)))
+{
+error(pure function '%s' cannot call impure function '%s',
+outerfunc-toChars(), f-toChars());
+}
}
#else
if (sc-func sc-func-isPure() !sc-intypeof !f-isPure())
-error(pure function '%s' cannot call impure function '%s'\n,
+error(pure function '%s' cannot call impure function '%s',
sc-func-toChars(), f-toChars());
#endif
}
@@ -1315,7 +1329,7 @@
{
if (sc-func sc-func-isSafe() !sc-intypeof
!f-isSafe() !f-isTrusted())
-error(safe function '%s' cannot call system function '%s'\n,
+error(safe function '%s' cannot call system function '%s',
sc-func-toChars(), f-toChars());
}
#endif
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3408] compiler asks for object.d when it really expects object.di
http://d.puremagic.com/issues/show_bug.cgi?id=3408 Jonathan M Davis jmdavisp...@gmail.com changed: What|Removed |Added CC||jmdavisp...@gmail.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmail.com 2010-03-10 15:55:55 PST --- Actually, I'd argue in this particular instance, since we know that the compiler failing to find object.d means that the user doesn't have their paths set up correctly (probably due to a bad dmd.conf or a the wrong one being found first), it would be beneficial to give a much more specific error that indicated that dmd couldn't find the standard libraries because the paths or dmd.conf were not set up correctly. Also, it would be very useful for the first time user if this problem were specifically mentioned on the installation page for dmd with instructions as to the likely causes (missing dmd.conf, poorly configured dmd.conf, find wrong dmd.conf first, etc). It would make it much friendlier for people to try and install D for the first time - particularly since this is a fairly common problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3929] New: GC.free() creates subtle bugs
http://d.puremagic.com/issues/show_bug.cgi?id=3929 Summary: GC.free() creates subtle bugs Product: D Version: 2.041 Platform: Other OS/Version: Windows Status: NEW Severity: regression Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: dsim...@yahoo.com --- Comment #0 from David Simcha dsim...@yahoo.com 2010-03-10 20:17:24 PST --- See bug 3930 for one observable manifestation of this bug, though I'm filing this as a separate bug report because it's probably the root cause of a lot of general weird behavior I've noticed in 2.041. It seems that, when GC.free() is called on an array now that Steve's LRU patch is in, the BlkInfo stays in the LRU cache, leading to subtle bugs. The patch seems to rely on the reference from cache preventing the array from getting GC'd. This is also bad in that it prevents memory from being reclaimed. A proper fix would be for the cache to be cleared whenever the GC runs or GC.free() is called. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3930] New: AAs horribly broken
http://d.puremagic.com/issues/show_bug.cgi?id=3930
Summary: AAs horribly broken
Product: D
Version: 2.041
Platform: Other
OS/Version: Windows
Status: NEW
Severity: regression
Priority: P1
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha dsim...@yahoo.com 2010-03-10 20:17:54 PST ---
The following code tests the builtin associative array by comparing its
behavior to the behavior of an AA implemented via linear search. It works on
2.040 but produces an access violation on 2.041.
import std.stdio, std.random;
// Quick, dirty and inefficient AA using linear search, useful for testing.
struct LinearAA(K, V) {
K[] keys;
V[] values;
V opIndex(K key) {
foreach(i, k; keys) {
if(k == key) {
return values[i];
}
}
assert(0, Key not present.);
}
V opIndexAssign(V val, K key) {
foreach(i, k; keys) {
if(k == key) {
return values[i] = val;
}
}
keys ~= key;
values ~= val;
return val;
}
V* opIn_r(K key) {
foreach(i, k; keys) {
if(key == k) {
return values.ptr + i;
}
}
return null;
}
void remove(K key) {
size_t i = 0;
for(; i keys.length; i++) {
if(keys[i] == key) {
break;
}
}
assert(i keys.length);
for(; i keys.length - 1; i++) {
keys[i] = keys[i + 1];
values[i] = values[i + 1];
}
keys = keys[0..$ - 1];
values = values[0..$ - 1];
}
uint length() {
return values.length;
}
}
void main() {
foreach(iter; 0..10) { // Bug only happens after a few iterations.
writeln(iter);
uint[uint] builtin;
LinearAA!(uint, uint) linAA;
uint[] nums = new uint[100_000];
foreach(ref num; nums) {
num = uniform(0U, uint.max);
}
foreach(i; 0..10_000) {
auto index = uniform(0, nums.length);
if(index in builtin) {
assert(index in linAA);
assert(builtin[index] == nums[index]);
assert(linAA[index] == nums[index]);
builtin.remove(index);
linAA.remove(index);
} else {
assert(!(index in linAA));
builtin[index] = nums[index];
linAA[index] = nums[index];
}
}
assert(builtin.length == linAA.length);
foreach(k, v; builtin) {
assert(k in linAA);
assert(*(k in builtin) == *(k in linAA));
assert(linAA[k] == v);
}
}
}
This is probably related to Bug 3929. Since the current builtin AA
implementation uses free() quite liberally as a practical necessity due to
false pointer issues, we see some very subtle, hard to reproduce bugs. (The
only way I can reproduce them is by monte carlo unittesting different AA
implementations against each other like above. Even then it depends somewhat
sensitively on what code was executed previously, hence the multiple
iterations.) For me, this is a blocker for using this version of DMD, as the
project I'm working on lately uses AAs very heavily. I think this is severe
enough to merit its own release.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3929] GC.free() creates subtle bugs
http://d.puremagic.com/issues/show_bug.cgi?id=3929 --- Comment #1 from David Simcha dsim...@yahoo.com 2010-03-10 20:30:47 PST --- Clarification: The LRU cache would avoid causing an otherwise GC-able array from being retained by casting the pointer to size_t or something and storing the BlkInfo struct somewhere that's not scanned completely conservatively, or maybe by xoring it with some arbitrary pattern. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3798] core.cpuid locks systems with Xeon E5530 CPU
http://d.puremagic.com/issues/show_bug.cgi?id=3798 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Don clugd...@yahoo.com.au 2010-03-10 20:49:23 PST --- Fixed DMD2.041. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3931] New: Associative Arrays on repeated stress testing get progressively slower
http://d.puremagic.com/issues/show_bug.cgi?id=3931 Summary: Associative Arrays on repeated stress testing get progressively slower Product: D Version: 2.040 Platform: x86 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: y0uf00...@gmail.com --- Comment #0 from Michael Rynn y0uf00...@gmail.com 2010-03-10 21:48:34 PST --- This occurs in both D1 and D2. For the specific test code where I noticed this, check out the aa project on dsource. I first noticed it on the original PyDict code, and then also noted built-in AA have similar behaviour. Looked at the Associative Arrays project on http://www.dsource.org/ projects/aa Ran the test program for PyDict noted the average result for consecutive runs of the one test it did, for uint[unit] associative arrays. This was very irritating, because of long wait for command line output. The test.d default sizes and number of runs were very big and only put out the average result at the end. Changed test.d to output each individual run time. The time for each individual run got progressively longer. This was fixable by making the calloc block attribute be GC.BlkAttr.NO_SCAN. So maybe the randomized uint bits confuse the garbage collector as it scans through. In the PyDictD1 test code there was a call to disable the garbage collector. Thats cheating. I looked at the code for PyDictD2.d and I decided that the table of struct Entry, holding the key and value, for which calloc is used , could be replaced by a more D - like (its a template anyway) call to new Entry[size]. The size is always a power of 2. Is it better to use new Entry[] rather than calloc, since the GC has a map of which values are pointers and which are not? Hopefully just like real D code. Ran the test again after removing the calloc, and the speed improved and the progressive run time increase went away. For comparison, I also put in a wrapper class template for the built in D AA type, and did the same tests. For uint[unit] this also had a progressive slow down in run-time. Same issue found for the D1 builtin AA. So the built-in associative array type of D suffers from this disease. (under very stressful array size parameters of course). It might affect long running programs with big builtin AA tables. The mystery is why was the slowdown progressive. After each run the AA variable is deleted, and the GC gets told to delete the calloc array directly. If the previous block of memory is properly gone, and a new cleared block created, shouldn't the run results be the same each time? So now the PyDict does not use calloc. and is faster than the built-in. I added a few missing properties (length, opIndex) The tests for string[uint] were re-instated. The built in AA had some progressive run slowdown tendency for this as well, although not as marked. A comment on the news group says its like a false sharing problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
