[Issue 4521] Array-wise assignment on unallocated array is accepted
http://d.puremagic.com/issues/show_bug.cgi?id=4521 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #3 from bearophile_h...@eml.cc 2010-07-28 04:19:38 PDT --- This is not a bug, I think this can be closed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4521] Array-wise assignment on unallocated array is accepted
http://d.puremagic.com/issues/show_bug.cgi?id=4521 --- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-07-28 05:55:29 PDT --- But isn't there a difference between arrays that had all of their elements removed and arrays that have not yet been allocated in the first place? I filed it since Walter seems to have confirmed this: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=114041 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4521] Array-wise assignment on unallocated array is accepted
http://d.puremagic.com/issues/show_bug.cgi?id=4521 --- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-07-28 06:38:07 PDT --- Actually I think I'm confusing myself with how dynamic allocation works. I thought the dynamic array always have to be called with new, but it appears I can change the length of an array without calling new in the first place, e.g.: int[] a; a.length = 4; a[] = 4; writeln(a); // writes 4 4 4 4 So this should probably get closed. Sorry for the confusion. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4521] Array-wise assignment on unallocated array is accepted
http://d.puremagic.com/issues/show_bug.cgi?id=4521 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4522] Write outputs Unicode incorrectly (on Windows)
http://d.puremagic.com/issues/show_bug.cgi?id=4522 Stewart Gordon s...@iname.com changed: What|Removed |Added Status|NEW |RESOLVED CC||s...@iname.com Resolution||DUPLICATE --- Comment #1 from Stewart Gordon s...@iname.com 2010-07-28 10:42:40 PDT --- *** This issue has been marked as a duplicate of issue 2742 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4520] add support for //! style documentation comments
http://d.puremagic.com/issues/show_bug.cgi?id=4520 --- Comment #6 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-07-28 11:24:39 PDT --- I'm afraid, it's useless. Doxygen uses its own markup and macros, they will be treated as plain text in ddoc comments. It's useless. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4516] forward declaration of enum not supported
http://d.puremagic.com/issues/show_bug.cgi?id=4516 --- Comment #3 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-07-28 11:41:50 PDT --- See bug 1160 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4397] const/CTFE does not work
http://d.puremagic.com/issues/show_bug.cgi?id=4397 --- Comment #4 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-07-28 12:04:59 PDT --- Shouldn't literals be immutable and the code - invalid? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #61 from Leandro Lucarella llu...@gmail.com 2010-07-28 12:23:01 PDT --- (In reply to comment #60) Created an attachment (id=701) [details] D1 - patch for Tango's runtime to enable precise GC scanning - lots of nasty refactoring in gcx.d: Even when I agree that the GC needs a lot of refactoring, I don't think it's a good idea to include it in this patch, it makes much harder to understand it and it might introduce some subtle bugs that will be very hard to track down in so many changes. I'm working on a GC that was based on the Tango (0.99.9) GC and doing a lot of refactoring myself. The refactoring of things introduced by the patch looks really nice though. Also, shouldn't functions like freeNoSync check for interior pointers? What happens if you call it with such a pointer? I don't think so, it should be undefined behavior (based on C's free()). Thanks! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4397] const/CTFE does not work
http://d.puremagic.com/issues/show_bug.cgi?id=4397 --- Comment #5 from Don clugd...@yahoo.com.au 2010-07-28 12:29:57 PDT --- (In reply to comment #4) Shouldn't literals be immutable and the code - invalid? I think they *should*. I argued strongly for immutable array literals. But I lost. So the code is valid, but likely to be very slow for a very long time. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #64 from Leandro Lucarella llu...@gmail.com 2010-07-28 13:04:07 PDT --- (In reply to comment #62) (In reply to comment #61) Even when I agree that the GC needs a lot of refactoring, I don't think it's a good idea to include it in this patch, it makes much harder to understand it and it might introduce some subtle bugs that will be very hard to track down in so many changes. I have to agree, but I did these changes in order to make storing a bitmask configurable, and to properly support SENTINEL. The changes the original patch did weren't very small either. I see 4 options: 1. keep this anyway 2. keep the old gcx.d around and apply the changes to a new incarnation of gcx.d, and let the user choose the GC implementation at startup or compile time 3. only accept the compiler patch, and wait for Leandro's new GC 4. revert to the previous version of my patch (of course I wouldn't like this at all) Which is it? I think this should be replied by whoever have the authority to merge the patches, my comments were just wishes (and you made them true in a much higher proportion that I was expecting :). I'd say 1 is OK. About my GC, is a research work and, even when my goal is something realistic and I'm doing performance tests all the time, don't expect much. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4397] const/CTFE does not work
http://d.puremagic.com/issues/show_bug.cgi?id=4397 --- Comment #6 from nfx...@gmail.com 2010-07-28 13:05:25 PDT --- It's not valid. This is a systems programming language, and the compiler can't just randomly insert memory allocations. What if you wrote a kernel in D? I insist on the wrong-code keyword. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2454] typeof(object) is incorrectly evaluated
http://d.puremagic.com/issues/show_bug.cgi?id=2454 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #6 from Don clugd...@yahoo.com.au 2010-07-28 13:21:29 PDT --- Fixed DMD2.023 (failed in 2.022). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4329] Do not show error messages that refer to __error
http://d.puremagic.com/issues/show_bug.cgi?id=4329
--- Comment #9 from bearophile_h...@eml.cc 2010-07-28 14:13:30 PDT ---
One case, dmd 2.047:
void main() {
auto x = foo.bar!();
}
test.d(2): Error: undefined identifier foo
test.d(2): Error: __error isn't a template
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4526] New: dmd crash with writeln of functions
http://d.puremagic.com/issues/show_bug.cgi?id=4526
Summary: dmd crash with writeln of functions
Product: D
Version: D2
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-07-28 14:49:50 PDT ---
D2 code, compiled with dmd 2.047:
import std.stdio;
void main() {
string a();
writeln(typeid(typeof(a)));
string function() b;
writeln(typeid(typeof(b)));
}
By the way, what's the point in allowing/keeping ugly and error-prone function
literals in D2?
It's better for D2 to keep/allow only _one_ standard, clean and readable syntax
for functions pointers (and one for delegates, if necessary). Keeping C
function pointer syntax or something similar in D2 causes troubles.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4526] dmd crash with writeln of functions
http://d.puremagic.com/issues/show_bug.cgi?id=4526 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from bearophile_h...@eml.cc 2010-07-28 15:25:51 PDT --- Closed because Brad Roberts has correctly noted this is a bug report and an enchantment request in one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4397] const/CTFE does not work
http://d.puremagic.com/issues/show_bug.cgi?id=4397 --- Comment #8 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-07-28 19:57:40 PDT --- Well... there can be a problem with immutable literals because immutability is transitive... hmm... Even if literals aren't immutable, compiler can still catch assignment of literal to mutable array and report error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
