[Issue 4269] Regression(2.031): invalid type accepted if evaluated while errors are gagged
http://d.puremagic.com/issues/show_bug.cgi?id=4269 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Severity|regression |normal -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4269] Regression(2.031): invalid type accepted if evaluated while errors are gagged
http://d.puremagic.com/issues/show_bug.cgi?id=4269 --- Comment #15 from Don clugd...@yahoo.com.au 2012-02-07 01:05:27 PST --- So far my patch fixes the original bug report, and about 60% of Daniel's extra test cases. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5915] Newlines are not propagated when copypasting code snippets
http://d.puremagic.com/issues/show_bug.cgi?id=5915 --- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-02-07 02:04:31 PST --- (In reply to comment #3) Where are you pasting the snippets of code? I'm using Opera (Win 7) and the text from http://d-programming-language.org/phobos/std_range.html is correctly pasted in a plethora of text editors, and text boxes from web pages. In a text editor that recognizes any form of newlines. I can confirm that it works ok in Opera, but not in Firefox. So this is some sort of browser compatibility issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4854] Regression(2.047, Mac 10.5 only) writefln Segmentation fault if no globals
http://d.puremagic.com/issues/show_bug.cgi?id=4854 --- Comment #15 from Jacob Carlborg d...@me.com 2012-02-07 04:21:38 PST --- I (In reply to comment #14) Is anyone still running 10.5? That's two OSX versions ago. I don't know. But I see now reason why we shouldn't support 10.5 as long as it doesn't cause too much problem. We're still supporting Windows XP which is two versions ago as well and is far older than Mac OS X 10.5. And yes, I know you can't really compare Mac OS X and Windows in this case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7456] New: Purity strength not documented
http://d.puremagic.com/issues/show_bug.cgi?id=7456 Summary: Purity strength not documented Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: rob...@octarineparrot.com --- Comment #0 from Robert Clipsham rob...@octarineparrot.com 2012-02-07 17:24:48 GMT --- The concepts of strong/weak purity are not documented (seems to be discussed in this thread: http://lists.puremagic.com/pipermail/dmd-beta/2011-July/000728.html ). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7456] Purity strength not documented
http://d.puremagic.com/issues/show_bug.cgi?id=7456 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-02-07 10:30:43 PST --- There is some debate as to whether they even should be. pure is defined quite correctly in the spec. weak vs strong purity is arguably just an implementation detail used for optimizations. I believe that this is Don's take on it (he's both the one who came up with strong vs weak purity and the one who updated the spec when pure was changed). Now, weak vs strong purity inevitably comes up when people get confused by why the compiler allows what are weakly pure functions to be pure (particularly when compared with what TDPL says - though I think that many just look at it from a functional perspective and are confused even without having read TDPL). So, there is arguably merit in defining them somewhere. But I believe that Don's against it. He's mentioned before that he wants the terms to go away entirely. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7457] New: nested pure functions not specified
http://d.puremagic.com/issues/show_bug.cgi?id=7457
Summary: nested pure functions not specified
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-02-07 10:53:41 PST ---
I think the following behavior of DMD is not mirrored in the documentation.
void main(){
int x;
void foo()pure{x=2;} // error
}
I think the spec is right, making this an error is problematic:
int bar(int delegate()pure dg)pure{return dg();}
int foo(int x)pure{
return bar({return x+1;});// error
}
struct Delegate{
int function(int*)pure fun;
int* context;
int call()pure{return fun(context);}
}
int bar2(Delegate dg)pure{return dg.call();}
int foo2(int x)pure{
return bar2(Delegate(function(int* ptr){return *ptr+1;}, x)); // fine
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7458] New: documentation claims non-existent limitation of nested aggregate member functions
http://d.puremagic.com/issues/show_bug.cgi?id=7458
Summary: documentation claims non-existent limitation of nested
aggregate member functions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: spec
Severity: normal
Priority: P2
Component: websites
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-02-07 10:57:52 PST ---
d-programming-language.org/function claims:
Member functions of nested classes and structs do not have access to the stack
variables of the enclosing function, but do have access to the other symbols:
void test() {
int j;
static int s;
struct Foo {
int a;
int bar() {
int c = s; // ok, s is static
int d = j; // error, no access to frame of test()
int foo() {
int e = s;// ok, s is static
int f = j;// error, no access to frame of test()
return c + a; // ok, frame of bar() is accessible,
// so are members of Foo accessible via
// the 'this' pointer to Foo.bar()
}
return 0;
}
}
}
However, this is wrong. DMD compiles the code fine.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7459] New: working around nested function declaration order
http://d.puremagic.com/issues/show_bug.cgi?id=7459
Summary: working around nested function declaration order
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: spec
Severity: enhancement
Priority: P2
Component: websites
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-02-07 11:04:28 PST ---
d-programming-language.org/function sez:
Unlike module level declarations, declarations within function scope are
processed in order. This means that two nested functions cannot mutually call
each other:
void test() {
void foo() { bar(); } // error, bar not defined
void bar() { foo(); } // ok
}
The solution is to use a delegate:
void test() {
void delegate() fp;
void foo() { fp(); }
void bar() { foo(); }
fp = bar;
}
The proposed solution is unnecessarily complicated and non-optimal. Since
nested template functions are instantiated with the state of the symbol table
of the lexically first instantiation, this is a superior solution:
void test() {
void foo()() { bar(); } // ok
void bar() { foo(); } // ok
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7452] Function using enforce() cannot be inferred as @safe because of anonymous function due to lazy argument
http://d.puremagic.com/issues/show_bug.cgi?id=7452
kenn...@gmail.com changed:
What|Removed |Added
Summary|Function using enforce()|Function using enforce()
|cannot be inferred as @safe |cannot be inferred as @safe
|because of the lazy |because of anonymous
|argument|function due to lazy
||argument
--- Comment #1 from kenn...@gmail.com 2012-02-07 12:10:39 PST ---
Further reduced test case, showing the cause is the function/delegate type, not
'lazy'.
-
int f7452c()(int x)
{
auto y = function int() { return 0; };
return x;
}
void g7452c() pure nothrow @safe
{
assert(4 == f7452c(4));
}
-
Note that 'pure' and 'nothrow' are correctly inferred.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5076] std.algorithm.sorted / schwartzSorted
http://d.puremagic.com/issues/show_bug.cgi?id=5076
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #13 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-02-07
12:20:02 PST ---
I run into this issue all the time, in particular when doing script-based
programming. E.g.:
string[string] classes;
foreach (name; classes.keys.sorted) { } // ng
Having to do this is a chore:
auto keys = classes.keys;
sort(keys);
foreach (name; keys) { }
This works ok for my purposes (yada yada about constraints):
T sorted(T)(T t)
{
T result = t;
sort(result);
return result;
}
Why do we have replace and replaceInPlace, whereas we have sort which sorts in
place implicitly? findSkip is another function that I sometimes use but I
hate how it hides the fact that it modifies its arguments. find returns a
range, but findSkip returns a bool and *modifies* your argument. It's not at
all obvious from the call site.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7452] Function using enforce() cannot be inferred as @safe because of anonymous function due to lazy argument
http://d.puremagic.com/issues/show_bug.cgi?id=7452 kenn...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from kenn...@gmail.com 2012-02-07 13:01:01 PST --- https://github.com/D-Programming-Language/dmd/pull/700 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6332] Auto-return function cannot be inferred as @safe
http://d.puremagic.com/issues/show_bug.cgi?id=6332 kenn...@gmail.com changed: What|Removed |Added Keywords|patch |pull --- Comment #2 from kenn...@gmail.com 2012-02-07 13:01:45 PST --- Also https://github.com/D-Programming-Language/dmd/pull/700 (o_O??) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 d...@dawgfoto.de changed: What|Removed |Added CC||d...@dawgfoto.de --- Comment #10 from d...@dawgfoto.de 2012-02-07 13:57:03 PST --- Perhaps changing map to make its inner struct 'static' (so it won't require a context pointer) will do the trick. This is a no-go, it would break every map parameter that needs a frame pointer. int base = 2; map!(a = a + base)(new int[](10)); What we should do to solve this is to infer if a templated struct really needs a frame pointer, thus creating less nested structs in the first place. Other than that it doesn't make sense to allow instantiation of nested structs outside of their scope. We should refine the specification. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #11 from Walter Bright bugzi...@digitalmars.com 2012-02-07 15:31:45 PST --- (In reply to comment #10) int base = 2; map!(a = a + base)(new int[](10)); What we should do to solve this is to infer if a templated struct really needs a frame pointer How else could it access 'base'? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
bug: Console buffer not flushed at right time
==
Bug:
--
1) Console output buffer is not flushed when it should be.
==
Example Code:
--
import std.stdio;
extern (Windows): uint GetConsoleOutputCP();
extern (Windows): bool SetConsoleOutputCP(uint codePageId);
void main()
{
auto oldCP = [GetConsoleOutputCP(),SetConsoleOutputCP(65001)];
scope(exit) if(oldCP[1]) SetConsoleOutputCP(oldCP[0]);
string str = H\u266a!;
foreach (wchar c; str)
{
write(c,' ');
}
}
==
What should happen:
--
When main starts, the console codepage is set to UTF 8. Characters are then
output to the console, and then the console codepage is reset to what it was
prior to program execution. The reset is neccessary to preserve the console
environment that exists prior to the program being run.
==
What happens instead:
--
Instead of outputting the characters while the console is in the requested
codepage, output is buffered. When main exits, the buffer is flushed, but after
the scope(exit) statement has reset the codepage, so the flushed output is
output while the wrong codepage is selected.
==
Work arounds:
--
a) Get console input first - Buffer appears to be flushed before accepting
input from the console.
b) Output a carriage return - Buffer appears to be flushed after every carriage
return
c) Explicit flush in scope(exit) - import std.cstream, call dout.flush() in the
scope(exit) statement
d) Patch the runtime to set the console codepage to unicode after opening a
console and then set it back to what it was on program exit - Makes sense since
all strings are output in unicode, and I wouldn't have to use win32 apis to get
logical behavior.
--= Posted using GrabIt =
--= Binary Usenet downloading made easy =-
-= Get GrabIt for free from http://www.shemes.com/ =-
[Issue 7394] ddmangle tool needs rebuilding
http://d.puremagic.com/issues/show_bug.cgi?id=7394 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: bug: Console buffer not flushed at right time
Please report bugs to d.puremagic.com/issues. This list is not supposed to be
posted to directly by users. You sign up for it if you want to see all of the
updates to bugs on Bugzilla.
- Jonathan M Davis
On Tuesday, February 07, 2012 15:49:19 Kevin Brogan wrote:
==
Bug:
--
1) Console output buffer is not flushed when it should be.
==
Example Code:
--
import std.stdio;
extern (Windows): uint GetConsoleOutputCP();
extern (Windows): bool SetConsoleOutputCP(uint codePageId);
void main()
{
auto oldCP = [GetConsoleOutputCP(),SetConsoleOutputCP(65001)];
scope(exit) if(oldCP[1]) SetConsoleOutputCP(oldCP[0]);
string str = H\u266a!;
foreach (wchar c; str)
{
write(c,' ');
}
}
==
What should happen:
--
When main starts, the console codepage is set to UTF 8. Characters are then
output to the console, and then the console codepage is reset to what it
was prior to program execution. The reset is neccessary to preserve the
console environment that exists prior to the program being run.
==
What happens instead:
--
Instead of outputting the characters while the console is in the requested
codepage, output is buffered. When main exits, the buffer is flushed, but
after the scope(exit) statement has reset the codepage, so the flushed
output is output while the wrong codepage is selected.
==
Work arounds:
--
a) Get console input first - Buffer appears to be flushed before accepting
input from the console.
b) Output a carriage return - Buffer appears to be flushed after every
carriage return
c) Explicit flush in scope(exit) - import std.cstream, call dout.flush() in
the scope(exit) statement
d) Patch the runtime to set the console codepage to unicode after opening a
console and then set it back to what it was on program exit - Makes sense
since all strings are output in unicode, and I wouldn't have to use win32
apis to get logical behavior.
--= Posted using GrabIt =
--= Binary Usenet downloading made easy =-
-= Get GrabIt for free from http://www.shemes.com/ =-
[Issue 5939] Cannot copy std.algorithm.map
http://d.puremagic.com/issues/show_bug.cgi?id=5939 --- Comment #12 from d...@dawgfoto.de 2012-02-07 19:06:25 PST --- Ah, I didn't wanted to confuse here. My example was a case for why Result could not be a static struct. As such it shouldn't be default constructible. David's example OTOH is a case where a context pointer in Result is not needed at all, i.e. we don't need to treat it as nested struct. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1448] UTF-8 output to console is seriously broken
http://d.puremagic.com/issues/show_bug.cgi?id=1448 Kevin ke...@brogan.ca changed: What|Removed |Added CC||ke...@brogan.ca --- Comment #7 from Kevin ke...@brogan.ca 2012-02-07 22:48:48 PST --- Sort of works for me. The text doesn't get cut off, but the unicode characters don't get displayed either. C:\Users\Kevin\Documents\D Projects\ConsoleApp1\ConsoleApp1\binConsoleApp1.exe Output utf-8 accented char é ... and the rest is OK Output utf-8 accented char �� ... and the rest is cut off! STDOUT. STDERR. C:\Users\Kevin\Documents\D Projects\ConsoleApp1\ConsoleApp1\bin -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7451] [Git regression] AAs broken for interfaces keys and values with opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=7451
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2012-02-07
23:07:47 PST ---
Is this really a regression?
Note that this also similarly fails:
interface Test {}
bool foo(Test x, Test y) {
return x == y;
}
foo2.d(6): Error: function object.opEquals (const(Object) lhs, const(Object)
rhs) is not callable using argument types (Test,Test)
Because an interface cannot be implicitly converted to an Object:
interface Test {}
Object foo(Test x) {
return x;
}
foo2.d(6): Error: cannot implicitly convert expression (x) of type foo2.Test to
object.Object
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
