[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)
https://issues.dlang.org/show_bug.cgi?id=14251 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/4b74c5f687a06d95c4ffe6e8aefe10f88acc098b Remove deprecated `std.concurrency.MessageBox.isClosed() const`. Within Phobos, this is the only occurrence of synchronizing on an immutable object. Removal of this deprecated function allows us to resolve Issue 14251. --
[Issue 15845] Windows console cannot read properly UTF-8 lines
https://issues.dlang.org/show_bug.cgi?id=15845 --- Comment #1 from Steven Schveighoffer--- *** Issue 15846 has been marked as a duplicate of this issue. *** --
[Issue 15846] Windows console cannot read properly UTF-8 lines
https://issues.dlang.org/show_bug.cgi?id=15846 Steven Schveighofferchanged: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Resolution|--- |DUPLICATE --- Comment #1 from Steven Schveighoffer --- *** This issue has been marked as a duplicate of issue 15845 *** --
[Issue 15846] New: Windows console cannot read properly UTF-8 lines
https://issues.dlang.org/show_bug.cgi?id=15846 Issue ID: 15846 Summary: Windows console cannot read properly UTF-8 lines Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: jv_vor...@msn.com module runnable; import std.stdio; import std.string : chomp; import std.experimental.logger; void doSomethingElse(char[] data) { writeln("hello!"); } int main(string[] args) { /* Some fix I found in UTF-8 related problems, I'm using Windows 10 */ version(Windows) { import core.sys.windows.windows; if (SetConsoleCP(65001) == 0) throw new Exception("failure"); if (SetConsoleOutputCP(65001) == 0) throw new Exception("failure"); } FileLogger fl = new FileLogger("log.log"); char[] readerBuffer; readln(readerBuffer); readerBuffer = chomp(readerBuffer); fl.info(readerBuffer.length); /* <- if the readed string contains at least one UTF-8 char this gets 0, else it prints its length */ if (readerBuffer != "exit") doSomethingElse(readerBuffer); /* Also, all the following code doesn't run as expected, the program doesn't wait for you, it executes readln() even without pressing/sending a key */ readln(readerBuffer); fl.info(readerBuffer.length); readln(readerBuffer); fl.info(readerBuffer.length); readln(readerBuffer); fl.info(readerBuffer.length); readln(readerBuffer); fl.info(readerBuffer.length); readln(readerBuffer); fl.info(readerBuffer.length); return 0; } The code above doesn't work properly on windows if you input at least one of the following chars: á, é, í, ó, ú, ñ, à, è, ì, ò, ù (I haven't tried with others). This behaviour is reproducible ONLY using O.S. Windows. It has been tested in Debian and Mac OS X and it works correctly. Also is different for each mode: 32-bit (DMC stdlib) and 64-bit (MVSC stdlib).In both, the line is not read properly (I get a length of 0). On 32-bit, the program exits immediately, indicating it cannot read any more data. On 64-bit, the program continues to allow input. --
[Issue 15845] New: Windows console cannot read properly UTF-8 lines
https://issues.dlang.org/show_bug.cgi?id=15845 Issue ID: 15845 Summary: Windows console cannot read properly UTF-8 lines Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: jv_vor...@msn.com module runnable; import std.stdio; import std.string : chomp; import std.experimental.logger; void doSomethingElse(char[] data) { writeln("hello!"); } int main(string[] args) { /* Some fix I found in UTF-8 related problems, I'm using Windows 10 */ version(Windows) { import core.sys.windows.windows; if (SetConsoleCP(65001) == 0) throw new Exception("failure"); if (SetConsoleOutputCP(65001) == 0) throw new Exception("failure"); } FileLogger fl = new FileLogger("log.log"); char[] readerBuffer; readln(readerBuffer); readerBuffer = chomp(readerBuffer); fl.info(readerBuffer.length); /* <- if the readed string contains at least one UTF-8 char this gets 0, else it prints its length */ if (readerBuffer != "exit") doSomethingElse(readerBuffer); /* Also, all the following code doesn't run as expected, the program doesn't wait for you, it executes readln() even without pressing/sending a key */ readln(readerBuffer); fl.info(readerBuffer.length); readln(readerBuffer); fl.info(readerBuffer.length); readln(readerBuffer); fl.info(readerBuffer.length); readln(readerBuffer); fl.info(readerBuffer.length); readln(readerBuffer); fl.info(readerBuffer.length); return 0; } The code above doesn't work properly on windows if you input at least one of the following chars: á, é, í, ó, ú, ñ, à, è, ì, ò, ù (I haven't tried with others). This behaviour is reproducible ONLY using O.S. Windows. It has been tested in Debian and Mac OS X and it works correctly. Also is different for each mode: 32-bit (DMC stdlib) and 64-bit (MVSC stdlib).In both, the line is not read properly (I get a length of 0). On 32-bit, the program exits immediately, indicating it cannot read any more data. On 64-bit, the program continues to allow input. --
[Issue 15844] how to create a program for the EK-LM3S8962 board, using the RODOS operating system, Present the time since startup in the board display (hh:mm:ss). Update this time every second and Bli
https://issues.dlang.org/show_bug.cgi?id=15844 ag0ae...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ag0ae...@gmail.com Resolution|--- |INVALID --- Comment #1 from ag0ae...@gmail.com --- This is not a place to ask for how-tos. If you have a question when learning D, post to the learn group in the forum: http://forum.dlang.org/group/learn Closing as invalid. --
[Issue 15844] New: how to create a program for the EK-LM3S8962 board, using the RODOS operating system, Present the time since startup in the board display (hh:mm:ss). Update this time every second an
https://issues.dlang.org/show_bug.cgi?id=15844 Issue ID: 15844 Summary: how to create a program for the EK-LM3S8962 board, using the RODOS operating system, Present the time since startup in the board display (hh:mm:ss). Update this time every second and Blink the board LED once every 5 seconds. Product: D Version: D2 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: varshini@gmail.com --
[Issue 15839] this.outer is of wrong type
https://issues.dlang.org/show_bug.cgi?id=15839 --- Comment #5 from Jacob Carlborg--- (In reply to Kenji Hara from comment #4) > However... of course it's not stable. And as far as I know, there's no way > to know the number of chains up to reach wanting enclosing scope. So the best approach would be to pass in the outer reference to the constructor when creating the anonymous class and use that instead of "this.outer"? --
[Issue 15843] New: D-type mangling used for extern(C) (extern) function declaration inside function body, on LDC, GDC, and DMD.
https://issues.dlang.org/show_bug.cgi?id=15843 Issue ID: 15843 Summary: D-type mangling used for extern(C) (extern) function declaration inside function body, on LDC, GDC, and DMD. Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: lasssa...@gmail.com Code: void main() { extern(C) extern int func(int); static assert(func.mangleof == "_D1x4mainFZ4funcUiZi"); } It is mangled as such on all 3 major compilers. Using "pragma(mangle, "func")" as an attribute for func gives: x.d(4): Error: unrecognized pragma(mangle) x.d(6): Error: undefined identifier 'func' x.d(7): Error: undefined identifier 'func' Seemingly, the only user-side fix is moving the declaration out of the function body. --
[Issue 13933] templatize object.opEquals
https://issues.dlang.org/show_bug.cgi?id=13933 Issue 13933 depends on issue 12537, which changed state. Issue 12537 Summary: Templatizing opEquals results in infinite recursion in the compiler https://issues.dlang.org/show_bug.cgi?id=12537 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 9769] Remove opEquals from Object
https://issues.dlang.org/show_bug.cgi?id=9769 Issue 9769 depends on issue 12537, which changed state. Issue 12537 Summary: Templatizing opEquals results in infinite recursion in the compiler https://issues.dlang.org/show_bug.cgi?id=12537 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12537] Templatizing opEquals results in infinite recursion in the compiler
https://issues.dlang.org/show_bug.cgi?id=12537 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12537] Templatizing opEquals results in infinite recursion in the compiler
https://issues.dlang.org/show_bug.cgi?id=12537 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a7ff19ae302948c4fd9e71034cc343d784137803 fix Issue 12537 - Templatizing opEquals results in infinite recursion in the compiler https://github.com/D-Programming-Language/dmd/commit/c150f4165ea50cd77e5c9e2ee0ef2f4bfd9027bb Merge pull request #5028 from 9rnsr/fix12537 Issue 12537 - Templatizing opEquals results in infinite recursion in the compiler --
[Issue 15832] Crashing program when a helper template function is used to create a template struct
https://issues.dlang.org/show_bug.cgi?id=15832 --- Comment #8 from ag0ae...@gmail.com --- (In reply to Atila Neves from comment #7) > In the following code, the length is garbage, and uncommenting an assert > makes the problem move! I think a garbage reference to the stack explains this well. Any change to the stack between the Mock construction and a call to dg affects what dg sees when it dereferences the garbage pointer. Adding/removing almost anything, including asserts, is going to change what's on the stack. You can also make the first assert in main fail. Or you can make the second one pass when trying hard enough: /* ... as above ... */ void messWithTheStack() {int[][4] x = void; x[0][0] = 42;} void main() { //auto m = Mock!(typeof(dg))(dg); auto m = mock(dg); // this should be equivalent but crashes assert(dg(3) == 0); m.returnValue(42); messWithTheStack(); assert(dg(3) == 42); } --
[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"
https://issues.dlang.org/show_bug.cgi?id=15498 --- Comment #7 from Kenji Hara--- (In reply to Steven Schveighoffer from comment #6) > Is there any way to define ComponentInfo or SharedString such that info and > baseClass overlap? I wouldn't think so. I don't know. So this is funny issue. I'm waiting more information from Manu. --
[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"
https://issues.dlang.org/show_bug.cgi?id=15498 --- Comment #6 from Steven Schveighoffer--- (In reply to Kenji Hara from comment #5) > If there's no unions (overlapped fields), the error print would be a > compiler bug. > > Honestly I cannot say anything until I see what the "some stuff" actually is. I would also like to see what is in there, but even without that, the error report is at least misleading. Note the error once again: Error: struct libep.componentdesc.ComponentDesc destructors, postblits and invariants are not allowed in overlapping fields info and baseClass And the struct ComponentDesc: struct ComponentDesc { ComponentInfo info; SharedString baseClass; } Is there any way to define ComponentInfo or SharedString such that info and baseClass overlap? I wouldn't think so. --
[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"
https://issues.dlang.org/show_bug.cgi?id=15498 --- Comment #5 from Kenji Hara--- (In reply to Steven Schveighoffer from comment #4) > But what about if there are no unions? Manu says no unions are being used. > > In his code, there is no unions where the error is being printed (info > conflicts with baseClass). If there's no unions (overlapped fields), the error print would be a compiler bug. Honestly I cannot say anything until I see what the "some stuff" actually is. --
[Issue 15779] DWARF EH fails when using stack stomping (-gx)
https://issues.dlang.org/show_bug.cgi?id=15779 --- Comment #10 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c388becdb50b78f4201fb1be91813b688ce8bbda fix Issue 15779 - DWARF EH fails when using stack stomping (-gx) https://github.com/D-Programming-Language/dmd/commit/2030b4abbe68d2f8b4b0221f15c9d6e065a2e3af Merge pull request #5579 from MartinNowak/fix15779 --
[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"
https://issues.dlang.org/show_bug.cgi?id=15498 --- Comment #4 from Steven Schveighoffer--- (In reply to Kenji Hara from comment #3) > Minimized example code that compiler shows the error message. But what about if there are no unions? Manu says no unions are being used. In his code, there is no unions where the error is being printed (info conflicts with baseClass). --
[Issue 15825] dmd's -transition=checkimports reports a false positive for tuple __dollar
https://issues.dlang.org/show_bug.cgi?id=15825 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a13a024a02ab62ba88cbe0f87815032d931f3090 fix Issue 15825 - dmd's -transition=checkimports reports a false positive for tuple __dollar https://github.com/D-Programming-Language/dmd/commit/cf273f717fb45ae4c0393c2eab7f0c4ed9e6e9ef Merge pull request #5567 from 9rnsr/fix15825 --
[Issue 15839] this.outer is of wrong type
https://issues.dlang.org/show_bug.cgi?id=15839 --- Comment #4 from Kenji Hara--- (In reply to Jacob Carlborg from comment #3) > So it's not representing the this reference of the outer class anymore? Until 2.070, the builtin .outer property sometimes returned correct class reference, sometimes invalid one. Test following code with 2.070 or earlier. import core.stdc.stdio : printf; interface Runnable {} class GC { this(AnimatedProgress ap) { printf("GC.ctor, ap = %p\n", ap); } } class AnimatedProgress { void start() { printf("start, this = %p\n", this); version(ng) int a; auto r = new class Runnable { void run() { printf("run, this.outer = %p\n", this.outer); GC gc = new GC(this.outer); version(ng) int b = a; } }; r.run(); } } void main() { auto ap = new AnimatedProgress(); printf("main, ap = %p\n", ap); ap.start(); } Without -version=ng, the class reference (instance address) are same, so the code would work as the author's expected. But with -version=ng, the start() member function will become a closure, and this.outer will suddenly return a pointer to the closure environment - of course it's invalid as a class reference. Note that, compiler cannot determine whether the start() makes a closure environment or not at the place where 'this.outer' is used. Because of that, the .outer property should have void* type, to be consistent with the lexical scope nesting. > Is > it possible to get that behavior somehow? > > This is a huge regression for DWT. Theoretically the chain of 'outer' can reach to AnimatedProgress class instance. Actually in my example code, following code can work in run() function with -version=ng case. version(ng) printf("run, *cast(void**)this.outer = %p\n", *cast(void**)this.outer); //GC gc = new GC(this.outer); GC gc = new GC(cast(AnimatedProgress)*cast(void**)this.outer); However... of course it's not stable. And as far as I know, there's no way to know the number of chains up to reach wanting enclosing scope. --
[Issue 7340] inout not resolved for default parameters
https://issues.dlang.org/show_bug.cgi?id=7340 Maksim Zholudevchanged: What|Removed |Added CC||maxim...@gmail.com --- Comment #1 from Maksim Zholudev --- DMD 2.070.2 inout(int) bar(inout(int) y = 0){return y;} pragma(msg, typeof(bar())); pragma(msg, typeof(bar(0))); Output: inout(int) int `inout` qualifier somehow escapes the context of `bar` function. --
[Issue 7211] Initializing const members in derived classes' constructors
https://issues.dlang.org/show_bug.cgi?id=7211 Maksim Zholudevchanged: What|Removed |Added CC||maxim...@gmail.com --- Comment #1 from Maksim Zholudev --- The error message has been changed. DMD 2.070.2: test.d(10): Error: cannot modify immutable expression this.x This is valid behavior if qualified members of classes are supposed to be dealt as described here: https://issues.dlang.org/show_bug.cgi?id=9665#c9 I wonder whether this is documented somewhere else. --
[Issue 7155] inconsistent .stringof
https://issues.dlang.org/show_bug.cgi?id=7155 Maksim Zholudevchanged: What|Removed |Added CC||maxim...@gmail.com Hardware|Other |All Severity|normal |enhancement --
[Issue 15832] Crashing program when a helper template function is used to create a template struct
https://issues.dlang.org/show_bug.cgi?id=15832 --- Comment #7 from Atila Neves--- In the following code, the length is garbage, and uncommenting an assert makes the problem move! import std.traits; import std.conv; int delegate(int) dg; static this() { dg = i => i * 2; } struct MockScope(T) { this(T)(ref T oldFunc, T newFunc) { _oldFuncPtr = _oldFunc = oldFunc; oldFunc = newFunc; } ~this() { *_oldFuncPtr = _oldFunc; } private: T* _oldFuncPtr; T _oldFunc; } struct Mock(T) { this(ref T func) { _returns = [ReturnType!T.init]; ReturnType!T inner(ParameterTypeTuple!T values) { auto ret = _returns[0]; assert(_returns.length < 10, "Weird length1: " ~ _returns.length.to!string); if(_returns.length > 1) _returns = _returns[1..$]; assert(_returns.length < 10, "Weird length2: " ~ _returns.length.to!string); return ret; } func = _scope = MockScope!(T)(func, ); } void returnValue(V...)(V value) { _returns.length = 0; foreach(v; value) _returns ~= v; // uncomment below and things work assert(_returns.length < 10, "Weird length3: " ~ _returns.length.to!string); } MockScope!T _scope; ReturnType!T[] _returns; } auto mock(T)(ref T f) { return Mock!T(f); } void main() { //auto m = Mock!(typeof(dg))(dg); auto m = mock(dg); // this should be equivalent but crashes assert(dg(3) == 0); m.returnValue(42); assert(dg(3) == 42); } --
[Issue 7098] Annoying Forward Reference Error When Compiling Multiple Files
https://issues.dlang.org/show_bug.cgi?id=7098 Maksim Zholudevchanged: What|Removed |Added CC||maxim...@gmail.com --- Comment #1 from Maksim Zholudev --- Seems to be fixed before 2.066.1-rc2 (tested on 64-bit Linux). I was unable to build older releases with Digger: 2.054 fails to build and 2.060 can't find object.d. --
[Issue 13116] Should not be able to return ref to 'this'
https://issues.dlang.org/show_bug.cgi?id=13116 --- Comment #13 from Kenji Hara--- https://github.com/D-Programming-Language/dmd/pull/5591 --
[Issue 15832] Crashing program when a helper template function is used to create a template struct
https://issues.dlang.org/show_bug.cgi?id=15832 --- Comment #6 from ag0ae...@gmail.com --- (In reply to Atila Neves from comment #5) > At least there's a workaround: > > auto m = Mock!T(...); > return m; > > I believe that the fact that this behaviour is different from the original > implementation is a compiler bug and would ask for this to reopened. I'm not sure if it's strictly a bug (against the spec), or if you're relying on an implementation detail when you assume construction at the destination. Either way, I agree that it's weird how adding a temporary makes the copy go away. I see a reasonable enhancement request, at least. You can reopen issues yourself. However, in this case I think we better open a new one. Did that here: issue 15842. I've added you to the CC list. > Also, the memory corruption that resulted from my original implementation > goes well beyong a delegate referencing gargabe. It was really weird. If there's anything else going on, could you provide a test case where that's more obvious? Or maybe point out how the additional corruption is visible in the code samples we have so far. --
[Issue 15842] New: struct is being copied when returned directly
https://issues.dlang.org/show_bug.cgi?id=15842 Issue ID: 15842 Summary: struct is being copied when returned directly Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Keywords: wrong-code Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: ag0ae...@gmail.com CC: atila.ne...@gmail.com This is spin-off from issue 15832. test.d: import std.stdio; struct S { this(int dummy) {writeln();} } S f() {return S(0);} void main() { S s = f(); writeln(); } The two `writeln`s print different addresses, so the struct is apparently constructed in a different location and gets copied on return. Change `f` to this and they print the same address: S f() {S s = S(0); return s;} I don't know what the ABI says about this, so this behavior may be allowed by the spec, but it's weird how adding a temporary makes the copy go away. --
[Issue 5040] opOpAssign should be automatically visible for types.
https://issues.dlang.org/show_bug.cgi?id=5040 Maksim Zholudevchanged: What|Removed |Added CC||maxim...@gmail.com Hardware|x86 |All OS|Windows |All Severity|normal |enhancement --- Comment #1 from Maksim Zholudev --- The same can be done with string mixin: T opIndexOpAssign(string op)(T value, int index) { return mixin("contents " ~ op ~ "= value"); } Anyway, the possibility to call operator as function (regardless whether it is defined explicitly or not) for both built-in and user-defined types could make this part of D more consistent. --
[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"
https://issues.dlang.org/show_bug.cgi?id=15498 --- Comment #3 from Kenji Hara--- Minimized example code that compiler shows the error message. struct X { this(this) {} // or: ~this() {} // or: invariant {} } union U // Error { X x; int overlapping; } struct S // Error { union { X x; int overlapping; } } For U or S, compiler cannot generate destructors, postblits, or invariants automatically, because the field x typed X overlapping with other fields. --
[Issue 15833] [REG2.071b] -m32mscoff always fails to link
https://issues.dlang.org/show_bug.cgi?id=15833 Kenji Harachanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12575] extern(C) mangling ignored inside mixin template
https://issues.dlang.org/show_bug.cgi?id=12575 Atila Neveschanged: What|Removed |Added CC||atila.ne...@gmail.com --- Comment #2 from Atila Neves --- The problem with this workaround is that it fails for `extern(C++)` unless you use `pragma(mangle, ` with the exact same mangling. --
[Issue 15832] Crashing program when a helper template function is used to create a template struct
https://issues.dlang.org/show_bug.cgi?id=15832 --- Comment #5 from Atila Neves--- At least there's a workaround: auto m = Mock!T(...); return m; I believe that the fact that this behaviour is different from the original implementation is a compiler bug and would ask for this to reopened. Also, the memory corruption that resulted from my original implementation goes well beyong a delegate referencing gargabe. It was really weird. Atila --
[Issue 15757] D main is a nested function and cannot be accessed
https://issues.dlang.org/show_bug.cgi?id=15757 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/35936ea3a5f3bcafebf1fd746a71aca7694e4af6 fix Issue 15757 - D main is a nested function and cannot be accessed https://github.com/D-Programming-Language/dmd/commit/d7a46615f3849450979c8e5fa384bc7035db8c11 Merge pull request #5574 from 9rnsr/fix15757 Issue 15757 - D main is a nested function and cannot be accessed --
[Issue 15835] Segfault with typeid call from lazy argument
https://issues.dlang.org/show_bug.cgi?id=15835 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/71294c1f4fdfad8d945b5e423e3c1ed02f30409d fix Issue 15835 - Segfault with typeid call from lazy argument https://github.com/D-Programming-Language/dmd/commit/39d6bfade540805b32282d6b542d7af8b126ad05 Merge pull request #5585 from 9rnsr/fix15835 Issue 15835 - Segfault with typeid call from lazy argument --
[Issue 15835] Segfault with typeid call from lazy argument
https://issues.dlang.org/show_bug.cgi?id=15835 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --