[Issue 6652] foreach parameter with number range is always ref
http://d.puremagic.com/issues/show_bug.cgi?id=6652 --- Comment #6 from d...@dawgfoto.de 2011-09-13 21:49:08 PDT --- It really is not that much an issue of performance. The compiler should be able to eliminate dead assignments and *& for ref parameters. The issue is that of breaking code. I don't know any feasible solution to attach a deprecation to this now and change it later. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6666] gc finalization/freeing is hierarchy agnostic
http://d.puremagic.com/issues/show_bug.cgi?id= d...@dawgfoto.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from d...@dawgfoto.de 2011-09-13 21:18:40 PDT --- Surprise, surprise. Seems like there is not much one can reliably do in a finalizer. Anyhow it was motivated by a C++ habit to do some clean up. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6666] gc finalization/freeing is hierarchy agnostic
http://d.puremagic.com/issues/show_bug.cgi?id= --- Comment #2 from Vladimir Panteleev 2011-09-13 18:05:56 PDT --- Oops, I broke it. > Furthermore, the order in which the garbage collector calls destructors > for unreference objects is not specified. This means that when the garbage > collector calls a destructor for an object of a class that has members that > are references to garbage collected objects, those references may no longer > be valid. This means that destructors cannot reference sub objects. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6666] gc finalization/freeing is hierarchy agnostic
http://d.puremagic.com/issues/show_bug.cgi?id= Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev 2011-09-13 18:04:22 PDT --- This is known, documented behavior. From http://www.d-programming-language.org/class.html#destructors : > Furthermore, the order in which the garbage collector calls destructors for > unreference objects is not specified. This means that when the garbage > collector calls a destructor for an object of a class that has members that > are references to garbage collected objects, those references may no longer > be valid. This means that destructors cannot reference sub objects. (In reply to comment #0) > It seems like we need to somehow sort the to be finalized memory while > scanning. What about cyclic references? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6666] New: gc finalization/freeing is hierarchy agnostic
http://d.puremagic.com/issues/show_bug.cgi?id=
Summary: gc finalization/freeing is hierarchy agnostic
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2011-09-13 17:58:47 PDT ---
class A
{
~this() {}
void cleanup() {}
}
class B
{
this(A a) { this.a = a; }
~this() { a.cleanup(); }
A a;
}
void main() {
auto a = new A();
auto b = new B(a);
// allocating a at a lower address than b causes it to be finalized earlier
assert(cast(void*)b.a < cast(void*)b);
}
---
Finalization is done in memory order and does not take
hierarchies into account.
When b.a is finalized before b it's vtable is set to null, hence
a segfault will happen when accessing the vtable.
Anyhow a is destroyed before b even though it is referenced by b.
It seems like we need to somehow sort the to be finalized memory while
scanning.
Any cheap ideas to do that are welcome.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6014] rt_finalize Segmentation fault , dmd 2.053 on linux & freebsd
http://d.puremagic.com/issues/show_bug.cgi?id=6014
d...@dawgfoto.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Comment #18 from d...@dawgfoto.de 2011-09-13 17:52:15 PDT ---
@changlon
You won't like the cause of your bug.
All fields in a struct are default initialized.
Pointers with null, Integrals with 0, Floats with NaN and enums with
the first enum member.
enum BlkAttr : uint
{
FINALIZE= 0b_0001, /// Finalize the data in this block on collect.
NO_SCAN = 0b_0010, /// Do not scan through this block on collect.
NO_MOVE = 0b_0100, /// Do not move this memory block on collect.
APPENDABLE = 0b_1000, /// This block contains the info to allow
appending.
NO_INTERIOR = 0b0001_
}
That means the attr flag in your memory pool is always set to BlkAttr.FINALIZE.
Every GC.malloc you do will get a wrong finalization.
It can be avoided this by giving a default value to the field.
GC.BlkAttr attr = cast(GC.BlkAttr)0;
Arguably this could be the default member in BlkAttr.
I will close this bug and open a new one for the order of class finalization.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6014] rt_finalize Segmentation fault , dmd 2.053 on linux & freebsd
http://d.puremagic.com/issues/show_bug.cgi?id=6014
d...@dawgfoto.de changed:
What|Removed |Added
CC||d...@dawgfoto.de
--- Comment #17 from d...@dawgfoto.de 2011-09-13 17:13:13 PDT ---
It could as well be a double finalization.
The vtable pointer is cleared when calling rt_finalize on a class.
There is also a deterministic bug happening due to an oversight in the
finalization design. Finalization is done in memory order and does not take
hierarchies into account.
---
class A
{
~this() {}
void cleanup() {}
}
class B
{
this(A a) { this.a = a; }
~this() { a.cleanup(); }
A a;
}
void main() {
auto a = new A();
auto b = new B(a);
// allocating a at a lower address than b causes it to be finalized earlier
assert(cast(void*)b.a < cast(void*)b);
}
---
When b.a is finalized before b it's vtable is set to null, hence
the segfault at accessing the classinfo.
It seems like we need to somehow sort the to be finalized memory while
scanning.
Any cheap ideas to do that are welcome.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6665] New: DMD explodes!
http://d.puremagic.com/issues/show_bug.cgi?id=6665
Summary: DMD explodes!
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: iteronve...@gmail.com
--- Comment #0 from iteronve...@gmail.com 2011-09-13 15:30:11 PDT ---
On a 64-bit Linux machine, with DMD 2.055
This gives: '/Internal error: ../ztc/cg87.c 202'
void main(){
auto f = (double m){ static double sum = 0.0; return sum += m * m; };
double[] a = array(map!f(iota(1.0, 25.0, 1.0)));
writeln(a);
}
This one compiles but I get Segmentation fault.
void main(){
auto f = (double m){ /* static double sum = 0.0;*/ return m * m; };
double[] a = array(map!f(iota(1.0, 25.0, 1.0)));
writeln(a);
}
This one compiles and runs.
void main(){
auto f = (double m){ /* static double sum = 0.0;*/ return m * m; };
double[] a = array(map!f(array(iota(1.0, 25.0, 1.0;
writeln(a);
}
Putting everything together, I still get 'Internal error: ../ztc/cg87.c 202'
with this one.
void main(){
auto f = (double m){ static double sum = 0.0; return sum += m * m; };
double[] a = array(map!f(array(iota(1.0, 25.0, 1.0;
writeln(a);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6663] std.stdio conflicts with core.stdc.stdio
http://d.puremagic.com/issues/show_bug.cgi?id=6663 --- Comment #3 from Vladimir Panteleev 2011-09-13 13:26:33 PDT --- A comment from std.cstream: * Both std.c.stdio and std.stream are publicly imported by std.cstream. I suppose this makes *some* kind of sense, if you think of std.cstream as an alternative, and not a complement, to std.stdio. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6664] BufferedFile this(HANDLE) uses undefined type.
http://d.puremagic.com/issues/show_bug.cgi?id=6664 --- Comment #4 from Jerry Quinn 2011-09-13 13:16:39 PDT --- (In reply to comment #3) > Sorry for the knee-jerk close, I thought you were talking about something in > std.stdio which allows construction from a HANDLE on Windows platforms. > > For the record, std.stream is generally regarded as obsolete code which simply > hasn't been rewritten yet. You may find that this is by far not the only poor > design decision in the module. That's certainly fine. It might make sense to put a note at the top of the std.stream page that features are subject to change. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6663] std.stdio conflicts with core.stdc.stdio
http://d.puremagic.com/issues/show_bug.cgi?id=6663 --- Comment #2 from Jerry Quinn 2011-09-13 13:14:05 PDT --- I think it's an error because I should be able to use facilities from the standard library without such conflict. Note that I'm not asking for guarantees about how the streams are synchronized, but it ought to compile and basically run. Sorry, I don't accept that a D user should have to distinguish between 2 stdout objects. A lot of effort is going into improving Phobos to make it civilized. This isn't. I do accept that std.stream is going to undergo a rework and that this issue may just disappear as part of that, though :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6664] BufferedFile this(HANDLE) uses undefined type.
http://d.puremagic.com/issues/show_bug.cgi?id=6664 --- Comment #3 from Vladimir Panteleev 2011-09-13 12:45:18 PDT --- Sorry for the knee-jerk close, I thought you were talking about something in std.stdio which allows construction from a HANDLE on Windows platforms. For the record, std.stream is generally regarded as obsolete code which simply hasn't been rewritten yet. You may find that this is by far not the only poor design decision in the module. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6664] BufferedFile this(HANDLE) uses undefined type.
http://d.puremagic.com/issues/show_bug.cgi?id=6664 Vladimir Panteleev changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #2 from Vladimir Panteleev 2011-09-13 12:42:12 PDT --- Ignore my last comment. HANDLE is aliased to int on Posix. BufferedFile is inside std.stream, and the constructor which takes a HANDLE is not in a version(Windows). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6663] std.stdio conflicts with core.stdc.stdio
http://d.puremagic.com/issues/show_bug.cgi?id=6663 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev 2011-09-13 12:35:47 PDT --- Why do you think this is a bug? Solutions to your problem include selective imports (import std.cstream : derr), or using disambiguation aliases (alias std.stdio.stdout stdout). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6664] BufferedFile this(HANDLE) uses undefined type.
http://d.puremagic.com/issues/show_bug.cgi?id=6664 Vladimir Panteleev changed: What|Removed |Added Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution||INVALID --- Comment #1 from Vladimir Panteleev 2011-09-13 12:38:11 PDT --- You are misunderstanding the purpose of such constructors. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6664] New: BufferedFile this(HANDLE) uses undefined type.
http://d.puremagic.com/issues/show_bug.cgi?id=6664 Summary: BufferedFile this(HANDLE) uses undefined type. Product: D Version: D2 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: jlqu...@optonline.net --- Comment #0 from Jerry Quinn 2011-09-13 12:27:30 PDT --- HANDLE is a Windows-specific type. It doesn't belong in the general Phobos API. However if it's going to be there, it needs to be a documented type and be obtainable in a platform-independent manner. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6663] New: std.stdio conflicts with core.stdc.stdio
http://d.puremagic.com/issues/show_bug.cgi?id=6663
Summary: std.stdio conflicts with core.stdc.stdio
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jlqu...@optonline.net
--- Comment #0 from Jerry Quinn 2011-09-13 12:21:08 PDT
---
DMD 2.055 on Ubuntu x86_64.
Compile the following junk.d file:
import std.stdio;
import std.cstream;
void main(string[] argv) {
derr.writef("CONTINUE ... \n");
stdout.write("hi\n");
}
~/dmd2/linux/bin64/dmd junk.d
junk.d(5): Error: std.stdio.stdout at
/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/stdio.d(2192) conflicts
with core.stdc.stdio.stdout at
/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/stdio.di(264)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3849] Compiler should catch incomplete initialisation of an array
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #18 from bearophile_h...@eml.cc 2011-09-13 04:28:51 PDT --- (In reply to comment #17) I have suggested to introduce the "..." syntax for arrays just because Walter thinks global arrays are often initialized partially. Some evidence shows this is a really uncommon need, so maybe it doesn't deserve a special syntax and it doesn't deserve to leave a trap in D that's a confirmed (by Don too) source of bugs. Don also has suggested a library solution that maybe makes "..." useless or less needed. > For what more valuable purpose do you wish to save the syntax I proposed? :) The first and main purpose of the "..." syntax is to denote a global/static fixed-sized array that is underspecified (and all items not specified default to T.init). You propose to add a secondary purpose to the "..." syntax, that allows to specify what's the value of all the not specified items, to ask for a value different from T.init. I have seen not even one use case for this sub-feature, this is bad for this idea. I my note about engineers I have tried to explain that engineers often have aversion of designs that conflate two different purposes into a single "user interface", especially if one of the purposes isn't a confirmed need and if it creates problems when it's used alongside other features (floating point numbers without leading digits). So I fear that the appreciation of Walter of this idea is _decreased_ by the idea of adding this sub-feature. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6662] New: std.functional.memoize with structs
http://d.puremagic.com/issues/show_bug.cgi?id=6662
Summary: std.functional.memoize with structs
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-09-13 04:18:51 PDT ---
In the following D2 program only the Mfoo1 compiles:
import std.functional: memoize;
struct Foo1 {
int x;
static Foo1 opCall(int x_) {
Foo1 f;
f.x = x_;
return f;
}
}
struct Foo2 {
int x;
}
struct Foo3 {
int x;
this(int x_) {
this.x = x_;
}
}
void main() {
alias memoize!Foo1 Mfoo1;
alias memoize!Foo2 Mfoo2;
alias memoize!Foo3 Mfoo3;
}
DMD 2.055 gives errors like:
...\src\phobos\std\traits.d(128): Error: static assert "argument has no return
type"
...\src\phobos\std\functional.d(713):instantiated from here:
ReturnType!(Foo2)
test.d(21):instantiated from here: memoize!(Foo2)
...\src\phobos\std\traits.d(128): Error: static assert "argument has no return
type"
...\src\phobos\std\functional.d(713):instantiated from here:
ReturnType!(Foo3)
test.d(22):instantiated from here: memoize!(Foo3)
The static assert is in std.traits:
template ReturnType(/+@@@BUG4217@@@+/func...)
if (/+@@@BUG4333@@@+/staticLength!(func) == 1)
{
static if (is(FunctionTypeOf!(func) R == return))
alias R ReturnType;
else
static assert(0, "argument has no return type");
}
I think Mfoo2 and Mfoo3 too should compile. Writing Foo2(5) is like calling the
function Foo2 with argument x = 5, and returning a struct Foo2 result. I think
this is a place where telling apart structs and functions is an artificial
distinction that is the opposite of useful.
See one use case:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=144333
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6652] foreach parameter with number range is always ref
http://d.puremagic.com/issues/show_bug.cgi?id=6652 --- Comment #5 from bearophile_h...@eml.cc 2011-09-13 03:59:49 PDT --- (In reply to comment #4) > https://github.com/D-Programming-Language/dmd/pull/377 > - I've double checked that a simple size_t index is optimized out if unaltered I suggest you to check it fifteen more times, using 4 nested foreach, with some code inside the bodies, with other data types (ubyte, short, ulong, real, double, etc), etc. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] Compiler should catch incomplete initialisation of an array
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #17 from Stewart Gordon 2011-09-13 03:38:12 PDT --- (In reply to comment #16) > An engineer usually prefers KISS designs, this also means that language > features serve for only one purpose. > The sub-feature you propose is cute, but I think seen from the eyes of an > engineer it risks reducing the value of the whole ellipsis feature :-| For what more valuable purpose do you wish to save the syntax I proposed? :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] Compiler should catch incomplete initialisation of an array
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #16 from bearophile_h...@eml.cc 2011-09-13 03:15:30 PDT --- (In reply to comment #14) > You don't have to use it then. You could use > float[6] arr = [1., 2., 42. ...]; > or > float[6] arr = [1., 2., 42...]; > or > float[6] arr = [1., 2., 42.0...]; > > instead. Right, but currently D doesn't require such syntaxes to write floating point values, so people are free to write the bad syntax, or you have to add one or more special cases to D. > with the comma, the remainder of elements > would be initialised to the type's .init. A ... following a value without a > comma would, OTOH, initialise all remaining elements to the specified value. An engineer usually prefers KISS designs, this also means that language features serve for only one purpose. The sub-feature you propose is cute, but I think seen from the eyes of an engineer it risks reducing the value of the whole ellipsis feature :-| -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6661] New: Templates instantiated only through is(typeof()) shouldn't cause errors
http://d.puremagic.com/issues/show_bug.cgi?id=6661
Summary: Templates instantiated only through is(typeof())
shouldn't cause errors
Product: D
Version: D1 & D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2011-09-13 02:44:40 PDT ---
The template blaz!int cannot be instantiated without errors, because it
contains an assignment of a string literal to int. But, since it is not
actually instantiated, it shouldn't cause a compile error.
template blaz(Q)
{
int qutz(Q y)
{
Q q = "abc";
return 67;
}
static assert(qutz(13).sizeof!=299);
const Q blaz = 6;
}
static assert(is(typeof(blaz!(int).blaz)));
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6660] New: Problem with SSE registers in array ops
http://d.puremagic.com/issues/show_bug.cgi?id=6660
Summary: Problem with SSE registers in array ops
Product: D
Version: D1 & D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2011-09-13 01:12:12 PDT ---
This program, arrayop.d,
void main()
{
double[4] a;
double[4] b;
a[] = b[] + b[];
}
compiled and run repeatedly in a batch file
dmd arrayop
arrayop
dmd arrayop
arrayop
dmd arrayop
arrayop
... (I put it in about 20 times)
eventually generates this error on a SandyBridge processor, Windows 7.
C:\sandbox\bugs>dmd arrayop
DMD v2.055 DEBUG
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Error 3: Cannot Create File arrayop.exe
--- errorlevel 1
Also happens in release version of DMD 2.055.
I think it is an SSE issue, since it only happens with arrays of floats and
doubles (not reals). But I'm just guessing. Maybe it is corrupting the stack.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6659] New: Destructor in range foreach called after initialization
http://d.puremagic.com/issues/show_bug.cgi?id=6659
Summary: Destructor in range foreach called after
initialization
Product: D
Version: D2
Platform: Other
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2011-09-13 00:11:52 PDT ---
void main()
{
static struct Iter
{
~this()
{
++_dtor;
}
bool opCmp(ref const Iter rhs) { return _pos == rhs._pos; }
void opUnary(string op:"++")() { ++_pos; }
size_t _pos;
static size_t _dtor;
}
foreach(ref iter; Iter(0) .. Iter(10))
{
assert(Iter._dtor == 0);
}
assert(Iter._dtor == 2);
}
---
The iteration is done using destructed instances.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6652] foreach parameter with number range is always ref
http://d.puremagic.com/issues/show_bug.cgi?id=6652 --- Comment #4 from d...@dawgfoto.de 2011-09-13 00:02:29 PDT --- https://github.com/D-Programming-Language/dmd/pull/377 Foreach arguments behave like function arguments. Here they don't. The variable can be optimized out, if no altering happens. This will not happen in a debug build, where it is irrelevant in comparison to every variable being accessed through the stack. You can use ref, if you're having too expensive copies foreach(ref const i; iter(0) .. iter(10)) as with every other foreach argument. Most important it has an explicit rule, that one can alter the loop index through using a ref index. foreach(ref idx, v; [0, 1, 2, 3, 4, 5]) idx += stride - 1; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
