[Issue 2812] sqrt(2.0) is about -2.7341e-53
http://d.puremagic.com/issues/show_bug.cgi?id=2812 bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from bugzi...@digitalmars.com 2009-04-08 00:26 --- Fixed dmd 2.028 --
[Issue 2820] New: itoa and ultoa functions are missing in Phobos
http://d.puremagic.com/issues/show_bug.cgi?id=2820 Summary: itoa and ultoa functions are missing in Phobos Product: D Version: 2.027 Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: bugzi...@digitalmars.com ReportedBy: 2kor...@gmail.com Starting from DMD2.027 (now that std.c.stdlib plain imports core.stdc.stdlib), a few of useful functions got lost. Namely itoa and ultoa. There might be other functions missing, too, I didn't investigate into it very well. --
[Issue 2819] array.sort segfaults if array length >=0x8F_FFFF
http://d.puremagic.com/issues/show_bug.cgi?id=2819 --- Comment #5 from s...@iname.com 2009-04-07 16:19 --- (In reply to comment #3) > I agree. By the way, if anyone has run numbers on the relative speeds of > various sort implementations, please share. What's a run number? Anyway, here's a program I wrote a while ago to benchmark sorting algorithms: http://www.digitalmars.com/d/archives/digitalmars/D/announce/Sorting_algorithms_benchmark_7661.html http://pr.stewartsplace.org.uk/d/sortbench.d --
[Issue 2819] array.sort segfaults if array length >=0x8F_FFFF
http://d.puremagic.com/issues/show_bug.cgi?id=2819 --- Comment #4 from matti.niemenmaa+dbugzi...@iki.fi 2009-04-07 15:17 --- http://www.dsource.org/projects/tango/ticket/571 has some old numbers. --
[Issue 2819] array.sort segfaults if array length >=0x8F_FFFF
http://d.puremagic.com/issues/show_bug.cgi?id=2819 --- Comment #3 from and...@metalanguage.com 2009-04-07 15:05 --- (In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > This is just another reason for the built-in .sort to be deprecated. > > > > I don't understand. How is this bug a consequence of sort being built in? > > It isn't. But the fact that the built-in sort is buggy as well as slow and > limited, further weakens its appeal. It just doesn't seem to have much going > for it. > I agree. By the way, if anyone has run numbers on the relative speeds of various sort implementations, please share. --
[Issue 2819] array.sort segfaults if array length >=0x8F_FFFF
http://d.puremagic.com/issues/show_bug.cgi?id=2819 --- Comment #2 from clugd...@yahoo.com.au 2009-04-07 14:47 --- (In reply to comment #1) > (In reply to comment #0) > > This is just another reason for the built-in .sort to be deprecated. > > I don't understand. How is this bug a consequence of sort being built in? It isn't. But the fact that the built-in sort is buggy as well as slow and limited, further weakens its appeal. It just doesn't seem to have much going for it. --
[Issue 2819] array.sort segfaults if array length >=0x8F_FFFF
http://d.puremagic.com/issues/show_bug.cgi?id=2819 s...@iname.com changed: What|Removed |Added CC||s...@iname.com Keywords||wrong-code --- Comment #1 from s...@iname.com 2009-04-07 14:20 --- (In reply to comment #0) > This is just another reason for the built-in .sort to be deprecated. I don't understand. How is this bug a consequence of sort being built in? --
[Issue 2818] New: Pointer parameters in core.memory should be const(void)*.
http://d.puremagic.com/issues/show_bug.cgi?id=2818 Summary: Pointer parameters in core.memory should be const(void)*. Product: D Version: 2.027 Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzi...@digitalmars.com ReportedBy: dsim...@yahoo.com In core.memory, functions that do not affect the validity or contents of the underlying memory regions should have signatures of ReturnType function(const void*), not ReturnType function(void*). These include GC.sizeOf(), GC.addrOf(), and GC.realloc(). There is simply no reason why these would be unsafe to call on pointers to const/immutable objects, and as such, this should not require an explicit cast. --
[Issue 2819] New: array.sort segfaults if array length >=0x8F_FFFF
http://d.puremagic.com/issues/show_bug.cgi?id=2819
Summary: array.sort segfaults if array length >=0x8F_
Product: D
Version: 1.042
Platform: PC
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: bugzi...@digitalmars.com
ReportedBy: clugd...@yahoo.com.au
void main() {
auto a = new uint[0x8F_]; // smallest size that fails
a.sort;
}
It's caused by the hard-coded
byte*[40] stack; // stack
in
extern (C) long _adSort(Array a, TypeInfo ti)
in qsort.d.
Affects both D1 and D2.
This is just another reason for the built-in .sort to be deprecated.
--
[Issue 2816] Sudden-death static assert is not very useful
http://d.puremagic.com/issues/show_bug.cgi?id=2816 --- Comment #5 from shro8...@vandals.uidaho.edu 2009-04-07 11:07 --- For that matter, if template errors could all be given optional (some flag?) stack traces (not just chained errors) that would be cool. I'm thinking somthing like: template error foo bla bla bla. invoked at file.d:7235 from TBar invoked at file.d:752 from TBaz invoked at code.d:7235 from Bling ... maybe (another flag?) some formatted printing of the args to (limited to 80 columns) --
[Issue 2816] Sudden-death static assert is not very useful
http://d.puremagic.com/issues/show_bug.cgi?id=2816 --- Comment #4 from clugd...@yahoo.com.au 2009-04-07 10:47 --- (In reply to comment #3) > Don, LDC already implemented template instantiation traces. Check > StaticAssert::semantic2 and TemplateInstance::printInstantiationTrace. I > emailed Walter about them at the time. If desired, I can provide a patch > against DMD. That'd be great! --
[Issue 2816] Sudden-death static assert is not very useful
http://d.puremagic.com/issues/show_bug.cgi?id=2816 kamm-removet...@incasoftware.de changed: What|Removed |Added Keywords||patch --- Comment #3 from kamm-removet...@incasoftware.de 2009-04-07 10:21 --- Don, LDC already implemented template instantiation traces. Check StaticAssert::semantic2 and TemplateInstance::printInstantiationTrace. I emailed Walter about them at the time. If desired, I can provide a patch against DMD. --
[Issue 2805] Many modules not labbeled as system
http://d.puremagic.com/issues/show_bug.cgi?id=2805 --- Comment #2 from bary...@smp.if.uj.edu.pl 2009-04-07 07:00 --- http://www.digitalmars.com/d/2.0/module.html#ModuleDeclaration --
[Issue 52] ambiguous function pointer silently accepted
http://d.puremagic.com/issues/show_bug.cgi?id=52 --- Comment #8 from s...@iname.com 2009-04-07 06:25 --- No. If you actually read this bug, you'll see that it isn't about lines 11 and 26, but about the fact that ambiguous function pointers are silently accepted. The errors should be at lines 6 and 20. If you take out the lines where errors actually are reported, you'll find that it incorrectly compiles without error (just checked in 1.043). Also, if there are Dstress testcases, please check these before proposing to close a bug. http://www.digitalmars.com/d/archives/digitalmars/D/bugs/bugzilla_usage_tips_10071.html --
[Issue 2816] Sudden-death static assert is not very useful
http://d.puremagic.com/issues/show_bug.cgi?id=2816 clugd...@yahoo.com.au changed: What|Removed |Added Keywords|patch | --- Comment #2 from clugd...@yahoo.com.au 2009-04-07 05:55 --- (In reply to comment #1) > The static assert does give you file/line, so it does give context. But I'll > add the expression print, too. > > But I think static assert errors should be fatal. They usually involve > misconfigured code, it is pointless to continue. > Yes, there will not be any more meaningful errors. But you still need a back trace. If the static assert occurs in (say) a library template, knowing that it happened in std.functional at line 92 doesn't help very much -- you want to know where the problem is in _your_ code. (That's a real example, BTW). Actually, I'll have another try, and see if I can create a backtrace, and THEN make it a fatal error. So I'm retracting this patch. --
[Issue 52] ambiguous function pointer silently accepted
http://d.puremagic.com/issues/show_bug.cgi?id=52 --- Comment #7 from g...@nwawudu.com 2009-04-07 05:31 --- (In reply to comment #6) > The example below does not compile... The example in the issue description does not compile anymore. Has this issue been fixed and is it ok to close this bug? --
[Issue 2817] optlink crashes because of utf8 string?
http://d.puremagic.com/issues/show_bug.cgi?id=2817 --- Comment #1 from dav...@126.com 2009-04-07 05:00 --- Created an attachment (id=317) --> (http://d.puremagic.com/issues/attachment.cgi?id=317&action=view) testutf.d dmd -g works, dmd testutf.d makes optlink crash --
Re: DMD returns -1073741819 despite success
A. Jung Wrote: > So its LINK.exe! Sorry, fingertrouble. Its definitly DMD.exe. Following happens when doing a fresh install of the entire DMD2.017 package and then replacing DMD.exe with the one from 2.016: "D:\test2>batmake D:\test2>dmd.exe -g -debug-IC:\dmd\src\phobos -c hello.d -ofobj\debug\hello.obj D:\test2>echo 0 0 D:\test2>dmd.exe bin\debug\test2.exe obj\debug\hello.obj phobos.lib -v C:\dmd\windows\bin\link.exe "obj\debug\hello","bin\debug\test2.exe",,"phobos.lib "+user32+kernel32/noi; D:\test2>echo 0 0"
[Issue 2817] New: optlink crashes because of utf8 string?
http://d.puremagic.com/issues/show_bug.cgi?id=2817 Summary: optlink crashes because of utf8 string? Product: D Version: unspecified Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Optlink AssignedTo: bugzi...@digitalmars.com ReportedBy: dav...@126.com err, it also relates to compile time evaluation i guess.. --
Re: DMD returns -1073741819 despite success
Now DMD2.017 with LINK2.016: "D:\test2>batmake D:\test2>dmd --help Digital Mars D Compiler v2.027 [...] D:\test2>link -H OPTLINK (R) for Win32 Release 8.00.1 [...] D:\test2>dmd.exe -g -debug-IC:\dmd\src\phobos -c hello.d -ofobj\debug\hello.obj D:\test2>echo 0 0 D:\test2>dmd.exe bin\debug\test2.exe obj\debug\hello.obj phobos.lib -v C:\dmd\windows\bin\link.exe "obj\debug\hello","bin\debug\test2.exe",,"phobos.lib "+user32+kernel32/noi; D:\test2>echo -1073741819 -1073741819" So its LINK.exe!
Re: DMD returns -1073741819 despite success
Unknown W. Brackets Wrote: > Try it from the command line. DMD 2.016: D:\test2>batmake D:\test2>dmd.exe -g -debug-IC:\dmd\src\phobos -c hello.d -ofobj\debug\hello.obj D:\test2>echo 0 0 D:\test2>dmd.exe bin\debug\test2.exe obj\debug\hello.obj phobos.lib D:\test2>echo 0 0" DMD 2.017: "D:\test2>batmake D:\test2>dmd.exe -g -debug-IC:\dmd\src\phobos -c hello.d -ofobj\debug\hello.obj D:\test2>echo 0 0 D:\test2>dmd.exe bin\debug\test2.exe obj\debug\hello.obj phobos.lib D:\test2>echo -1073741819 -1073741819" This has nothing to do with Codeblocks or directory structure. I suspect, this is probably related to the new mulithreading feature of DMD. I am running an "Intel(R) Core(TM)2 Quad CPU". Next, I'll try DMD2.017 with LINK2.016.
[Issue 2816] Sudden-death static assert is not very useful
http://d.puremagic.com/issues/show_bug.cgi?id=2816 --- Comment #1 from bugzi...@digitalmars.com 2009-04-07 04:21 --- The static assert does give you file/line, so it does give context. But I'll add the expression print, too. But I think static assert errors should be fatal. They usually involve misconfigured code, it is pointless to continue. --
[Issue 1309] sorting arrays of structs is broken
http://d.puremagic.com/issues/show_bug.cgi?id=1309 --- Comment #3 from g...@nwawudu.com 2009-04-07 04:13 --- The documentation for structs in associative array mentions that opCmp should be declared as 'int opCmp(ref const MyStruct x) const', this definition should be applied to standard arrays as well. The section 'Using Structs or Unions as the KeyType' should be applied to standard and associative arrays. So maybe this isue should be marked as a spec change? --
[Issue 2816] New: Sudden-death static assert is not very useful
http://d.puremagic.com/issues/show_bug.cgi?id=2816
Summary: Sudden-death static assert is not very useful
Product: D
Version: 1.042
Platform: PC
OS/Version: Windows
Status: NEW
Keywords: patch
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: clugd...@yahoo.com.au
Sudden-death static asserts were introduced due to comment #2 of bugzilla 77:
http://d.puremagic.com/issues/show_bug.cgi?id=77
However, they make static assert rather useless, since it gives you absolutely
no context. To make it useful again,
In staticassert.c, line 68 (in DMD2.027):
error("is false");
if (!global.gag)
fatal();
---
change this to:
error("(%s) is false", exp->toChars());
---
(ie, remove the global.gag test).
--
[Issue 52] ambiguous function pointer silently accepted
http://d.puremagic.com/issues/show_bug.cgi?id=52 --- Comment #6 from g...@nwawudu.com 2009-04-07 03:12 --- The example below does not compile. Has this been fixed? DMD v1.041 bug52.d(11): Error: expected 1 arguments, not 0 bug52.d(26): Error: expected 0 arguments, not 1 DMD v2.027 bug52.d(11): Error: expected 1 function arguments, not 0 bug52.d(20): Error: cannot infer type from overloaded function symbol & fn bug52.d(26): Error: expected 0 arguments, not 1 for non-variadic function type int() --
Re: DMD returns -1073741819 despite success
Well, for me it works. I do use the error level in some scripts I've written, and it outputs 0 when linking. I'm not linking in the lib file, though. Try it from the command line. I know you want it to work in the IDE, but the first step is to determine whose bug it is. From the command line, just execute the commands your IDE echos, and after each issue echo %errorlevel%. So: dmd.exe -g -debug-IC:\dmd\src\phobos -c hello.d -ofobj\debug\hello.obj echo %errorlevel% dmd.exe bin\debug\test2.exe obj\debug\hello.obj phobos.lib echo %errorlevel% If both times it returns 0, something funny is happening. Also, dmd.exe's return code is directly related to link.exe's return code. You could try using the link.exe from 2.016, and see if that works. If it does, maybe there's a bug in link.exe. If you can get a non-zero errorlevel, use dmd -v, it will output what it sends to link.exe... see if that command also gives the same errorlevel. -[Unknown] A. Jung wrote: For confirmation: same input, but DMD 2.016: "-- Build: debug in test2 --- dmd.exe -g -debug-IC:\dmd\src\phobos -c hello.d -ofobj\debug\hello.obj dmd.exe bin\debug\test2.exe obj\debug\hello.obj phobos.lib Output size is 96.53 KB Process terminated with status 0 (0 minutes, 0 seconds) 0 errors, 0 warnings"
[Issue 1927] dmd SEGV when passing invalid symbol as parameter
http://d.puremagic.com/issues/show_bug.cgi?id=1927 clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --
[Issue 2815] Attributes at end of file accepted
http://d.puremagic.com/issues/show_bug.cgi?id=2815
--- Comment #1 from clugd...@yahoo.com.au 2009-04-07 02:06 ---
Created an attachment (id=316)
--> (http://d.puremagic.com/issues/attachment.cgi?id=316&action=view)
fix 2815
Adds:
case TOKeof:
error("declaration expected following attribute, not EOF");
break;
to Parser::parseBlock() in parse.c, by analogy to the behaviour for semicolon.
--
[Issue 2812] sqrt(2.0) is about -2.7341e-53
http://d.puremagic.com/issues/show_bug.cgi?id=2812 --- Comment #3 from clugd...@yahoo.com.au 2009-04-07 02:08 --- Not so. float x = sqrt(2.0f); is also wrong. It only affects compile-time constants: double y = 2.0; double x = sqrt(y); works correctly. --
[Issue 2815] New: Attributes at end of file accepted
http://d.puremagic.com/issues/show_bug.cgi?id=2815 Summary: Attributes at end of file accepted Product: D Version: 1.042 Platform: PC OS/Version: Windows Status: NEW Keywords: accepts-invalid, patch Severity: trivial Priority: P2 Component: DMD AssignedTo: bugzi...@digitalmars.com ReportedBy: clugd...@yahoo.com.au A file consisting only of the line: --- public static nothrow pure extern --- compiles without error. This patch (for D2.027) makes it an error. (It remains OK to end with a colon). --
