[Issue 1752] std.date.LocalTimetoUTC applies wrong daylight savings time adjustments in EU timezones
http://d.puremagic.com/issues/show_bug.cgi?id=1752 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #6 from Jonathan M Davis 2011-05-24 23:43:19 PDT --- The std.date bugs are std.date-specific and have _nothing_ to do with std.datetime. Any and all std.date bugs are irrelvent to std.datetime and bugs for std.datetime should be submitted separately. However, while std.date is going away in D2, it's still around for D1, so std.date bugs still apply to D1, and they can't necessarily be closed (though I question that they'll ever be fixed). Notice that this bug is marked as D1-only. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 973] [std.date] DST (daylight savings time) not applied in southern hemisphere
http://d.puremagic.com/issues/show_bug.cgi?id=973 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #4 from Jonathan M Davis 2011-05-24 23:44:21 PDT --- It's a D1 bug, since std.date is still around in D1. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3145] std.perf documentation is generated, but there's no link to it from the side index
http://d.puremagic.com/issues/show_bug.cgi?id=3145 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||WONTFIX --- Comment #2 from Andrej Mitrovic 2011-05-24 23:37:09 PDT --- std.perf is deprecated. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 973] [std.date] DST (daylight savings time) not applied in southern hemisphere
http://d.puremagic.com/issues/show_bug.cgi?id=973 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #3 from Andrej Mitrovic 2011-05-24 23:34:38 PDT --- Probably fixed in datetime. Close it? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1512] GC infinite loop when invalid user code runs.
http://d.puremagic.com/issues/show_bug.cgi?id=1512 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #9 from Andrej Mitrovic 2011-05-24 23:22:00 PDT --- 2.053: object.Error: Access Violation 40D554 40D3CB I guess that means fixed? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1752] std.date.LocalTimetoUTC applies wrong daylight savings time adjustments in EU timezones
http://d.puremagic.com/issues/show_bug.cgi?id=1752 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #5 from Andrej Mitrovic 2011-05-24 23:17:20 PDT --- Jonathan, if you're around can you confirm that datetime doesn't suffer from this same issue? If so this should be closed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2255] AA.remove() doesn't remove AA element when iterating using foreach
http://d.puremagic.com/issues/show_bug.cgi?id=2255 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #6 from Jonathan M Davis 2011-05-24 22:53:28 PDT --- As I understand it, it is unsafe to remove members of an AA while iterating over it - and that includes unsafe in the memory sense. Perhaps something needs to be done so that it doesn't risk memory issues, but I wouldn't expect it to ever become something that would be expected to work (just not cause problems with memory). So, adding it to the docs would probably be a good idea. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2162] Access violation when threads run closures
http://d.puremagic.com/issues/show_bug.cgi?id=2162 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic 2011-05-24 22:45:34 PDT --- In 2.053 it will deny compiling this as it detects that run1 and run2 are delegates. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2255] AA.remove() doesn't remove AA element when iterating using foreach
http://d.puremagic.com/issues/show_bug.cgi?id=2255 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #5 from Andrej Mitrovic 2011-05-24 22:39:57 PDT --- Is it agreed that removing keys while traversing hashes is something you should never do? I could add some documentation on the AA page about this, if that's what everyone agrees to. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2335] Message on unicode error
http://d.puremagic.com/issues/show_bug.cgi?id=2335 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #2 from Andrej Mitrovic 2011-05-24 22:36:22 PDT --- It's been fixed, can't find "4invalid". -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2413] getche differs from getch unexpectedly
http://d.puremagic.com/issues/show_bug.cgi?id=2413 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||INVALID --- Comment #1 from Andrej Mitrovic 2011-05-24 22:32:04 PDT --- These symbols don't exist anymore. They were probably C functions anyway. RTFM! :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2467] strtol() is improperly declared
http://d.puremagic.com/issues/show_bug.cgi?id=2467 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #1 from Andrej Mitrovic 2011-05-24 22:28:54 PDT --- Fixed long ago in core.stdc.stdlib. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2813] implicit cast (implemented via alias this) is not triggered when returning from function
http://d.puremagic.com/issues/show_bug.cgi?id=2813 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #1 from Andrej Mitrovic 2011-05-24 22:26:46 PDT --- Works in 2.053: struct Proxy { private Object o; Object get() { return o; } alias get this; } class Bar { Object getObject() { return _proxy; // should work, but doesn't } private Proxy _proxy; } void main() { auto bar = new Bar(); auto proxy = bar.getObject(); assert(proxy is null); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2819] array.sort segfaults if array length >=0x8F_FFFF
http://d.puremagic.com/issues/show_bug.cgi?id=2819 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #6 from Andrej Mitrovic 2011-05-24 22:24:36 PDT --- I can't recreate this bug on 2.053. If others can confirm, close this down I guess. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3063] Importing std.dateparse and dependent files in DMD 2.030 causes DSSS/Rebuild to fail
http://d.puremagic.com/issues/show_bug.cgi?id=3063 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #1 from Andrej Mitrovic 2011-05-24 22:21:00 PDT --- Ancient but it's fixed, and this module is deprecated anyway. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3140] osx druntime path missing debug/release dir
http://d.puremagic.com/issues/show_bug.cgi?id=3140 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||WORKSFORME --- Comment #3 from Andrej Mitrovic 2011-05-24 22:17:18 PDT --- I think this can be closed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3191] std.zlib.UnCompress errors if buffer is reused
http://d.puremagic.com/issues/show_bug.cgi?id=3191 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic 2011-05-24 22:05:17 PDT --- Greetings, I come from the future. Here's a modern implementation of your sample: import std.zlib; import std.stdio; const size_t BLOCK_SIZE = 1024; void main(string[] a) { auto file = File(a[1], "r"); auto uc = new UnCompress(); void[] ucData; ubyte[] block = new ubyte[BLOCK_SIZE]; foreach (ubyte[] buffer; file.byChunk(BLOCK_SIZE)) { writeln(buffer.length); ucData ~= uc.uncompress(buffer); } ucData ~= uc.flush(); writefln("Finished: %s", ucData.length); } Still errors out. But I have a hunch it has something to do with buffer being reused by file.byChunk, and zlib might internally be storing a pointer to the buffer while the GC might deallocate it in the meantime. Something like that, because if you .dup your buffer, you won't get errors anymore: import std.zlib; import std.stdio; const size_t BLOCK_SIZE = 1024; void main(string[] a) { auto file = File(a[1], "r"); auto uc = new UnCompress(); void[] ucData; ubyte[] block = new ubyte[BLOCK_SIZE]; foreach (ubyte[] buffer; file.byChunk(BLOCK_SIZE)) { writeln(buffer.length); ucData ~= uc.uncompress(buffer.dup); } ucData ~= uc.flush(); writefln("Finished: %s", ucData.length); } It might just be that zlib expects all data passed in to be valid while you use the UnCompress() class. I have no other explanation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5396] Invalid code with nested functions in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=5396 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 2011-05-24 21:40:59 PDT --- Extended test cases (applies to delegate literals as well as inner functions): void bug5396(int b) { int inner() { return b; } static int staticInner() { return 6; } static assert(is(typeof(compiles!( function int () {return 7; }() ; static assert(!is(typeof(compiles!( delegate int () {return b; }() ; static assert(!is(typeof(compiles!( inner() ; static assert(is(typeof(compiles!( staticInner() ; } Patch in interpret.c, CallExp::interpret(). Problem is, this breaks bug 1461 which seems to be an important use case. if (!istate && fd && fd->isNested() && !fd->isStatic() && /* BUG: Delegate literals report 'isNested()' even if they are * declared at module scope. */ !(fd->isFuncLiteralDeclaration() && !fd->toParent2()->isFuncDeclaration())) { error("cannot directly interpret non-static nested function %s", fd->toChars()); return EXP_CANT_INTERPRET; } if (pthis && fd) { // Member function call -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3480] Overload Select to work on aliases
http://d.puremagic.com/issues/show_bug.cgi?id=3480 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #1 from Andrej Mitrovic 2011-05-24 21:38:52 PDT --- Seems to be fixed, it works for me using 2.053 (I have tested with -unittest). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3704] split(char[], char[]) is broken for delimiters greater than a single character
http://d.puremagic.com/issues/show_bug.cgi?id=3704 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2011-05-24 21:34:17 PDT --- Has this been fixed? I have no problem of using delimiters with sizes greater than 1: This works: import std.stdio; import std.string; void main() { foreach (item; "test test".split(" ")) { writefln("my data: %s", item); } } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3741] std.date YearFromTime broken or very slow
http://d.puremagic.com/issues/show_bug.cgi?id=3741 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #1 from Andrej Mitrovic 2011-05-24 21:28:15 PDT --- You can now use std.datetime.SysTime.year, as recommended in the "Migrating from std.date to std.datetime" article that will be up on DPL.org soon. import std.datetime; auto year = (cast(DateTime)Clock.currTime()).year; It takes 128 microseconds on my machine. Hope that's fast enough. Otherwise file a bug report for std.datetime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4032] std.date.makeTime has no docs
http://d.puremagic.com/issues/show_bug.cgi?id=4032 --- Comment #3 from Adam D. Ruppe 2011-05-24 21:11:05 PDT --- Yes, of course. I forgot I filed this at all - actually a lot of the functions I complained about did get documentation a little later. So definitely can be closed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4032] std.date.makeTime has no docs
http://d.puremagic.com/issues/show_bug.cgi?id=4032 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||WONTFIX --- Comment #2 from Andrej Mitrovic 2011-05-24 21:06:10 PDT --- Is it ok if I mark this as closed? std.date is deprecated and we should use std.datetime instead, which has plenty of documentation. std.date probably won't be updated anymore. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4295] IID_IUnknown symbol undefined in phobos.lib
http://d.puremagic.com/issues/show_bug.cgi?id=4295 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #6 from Andrej Mitrovic 2011-05-24 21:01:55 PDT --- If it's fixed, we shall close it. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4317] Calling std.string.split with static array for separator fails to compile
http://d.puremagic.com/issues/show_bug.cgi?id=4317 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||INVALID --- Comment #1 from Andrej Mitrovic 2011-05-24 20:59:35 PDT --- You have to pass a slice, e.g.: string[] sa = split("split me now", foo[]); and: split("some string", whitespace[]) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5190] std.stdio should have File.fdopen
http://d.puremagic.com/issues/show_bug.cgi?id=5190 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2011-05-24 20:34:36 PDT --- fdopen is declared in core\sys\posix\stdio.d It seems there's at least one function which uses it: D:\DMD\dmd2\src\phobos\std\stdio.d:2540:FILE* fp = enforce(fdopen(s, "w+".ptr)); Hope that helps in any way! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5228] Add GetOptException (or similar) to std.getopt
http://d.puremagic.com/issues/show_bug.cgi?id=5228 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic 2011-05-24 20:23:44 PDT --- It can also throw a UnicodeException. Even for things like this: main.exe - A single slash throws: core.exception.UnicodeException@(1244708): invalid UTF-8 sequence This should really be wrapped in some kind of a getopt exception. I'd further add that appart from getting some information on which option failed to parse, getopt might try to figure out what went wrong in other situations and create a custom exception message based on it. For example if you just pass a single dash getopt would throw GetOptException("Failed to provide an argument after single dash."), and you could either catch this and ignore it, or display it to the user: void main() { try { // parse args } catch (GetOptException exc) { writeln(exc.toString); // tell the user what went wrong, // but maybe continue operating } } Anywho, +1 for the enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5317] Assertion is not work in a function called by std.concurrency.spawn
http://d.puremagic.com/issues/show_bug.cgi?id=5317 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #3 from Andrej Mitrovic 2011-05-24 20:15:58 PDT --- I can't reproduce your first test case, but I can reproduce your second one. It seems as if the main thread eats up the exceptions. Maybe it has to do with buffered console output which isn't flushed properly? Here's another test case: import std.stdio, std.concurrency, std.conv, core.thread; void f() { assert(0); } void main() { auto tid = spawn(&f); Thread.sleep( dur!("seconds")( 2 ) ); } If you remove the call to sleep, the assertion will throw. So while the main thread is locked, something is blocking the exceptions from propagating? I've no idea.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2742] std.stdio assumes console works in utf-8
http://d.puremagic.com/issues/show_bug.cgi?id=2742 --- Comment #9 from Andrej Mitrovic 2011-05-24 20:01:07 PDT --- According to this page http://codesnippets.joyent.com/posts/show/414 you can get and set the codepage via the [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage] key's OEMCP value. Setting the codepage requires a restart though. Also, changing the codepage has other effects, e.g. using ALT+Numpad keys is handled differently (with codepage 1252 you don't have to prepend a zero when using ALT+Numkey apparently). Here's how to fetch the value: import std.stdio; import std.windows.registry; void main() { Key HKLM = Registry.localMachine; Key SFW = HKLM.getKey(r"SYSTEM\CurrentControlSet\Control\Nls\CodePage"); auto codePage = SFW.getValue("OEMCP").value_SZ(); writeln(codePage); } Note that the key type is REG_SZ, a string, not a binary value. So if you want to set the code page programmatically, you have to call: SFW.setValue("OEMCP", "1252"); One more thing, there was this comment: "Change the code page in your registry and you may not be able to reboot your windows anymore." That sounds kind of scary. Perhaps all of this should be left to the user to do and just document it somewhere in the docs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5610] std.getopt.getopt Access Violation
http://d.puremagic.com/issues/show_bug.cgi?id=5610 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||INVALID --- Comment #1 from Andrej Mitrovic 2011-05-24 19:24:35 PDT --- I'm testing this on v2.053. I suggest you upgrade to this version, it will give you nice stacktraces and a more useful error message. getopt only accepts a single argument with a single dash. You could pass a single unicode character if you want to e.g.: getopt_test.exe -ф And you'll get: getopt.d(411): Unrecognized option -ф which just means you have to write the code to handle such a case, but it works. Your multi-argument call will work if you prepend two dashes: import std.getopt; void main(string[] args) { bool test; getopt(args, "файл", &test); assert(test); } getopt_test.exe --файл So I'm closing this down, unless you find the bug persists. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5751] Small syntax error in Phobos 2.0.5.2
http://d.puremagic.com/issues/show_bug.cgi?id=5751 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #1 from Andrej Mitrovic 2011-05-24 19:03:17 PDT --- It was there in 2.052, but I can't find this call anymore in the 2.053 release because the module changed a lot. I think it's safe to mark that it was fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5914] std.range.ElementType has duplicated unittest, ElementEncodingType is missing one
http://d.puremagic.com/issues/show_bug.cgi?id=5914 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059 --- Comment #9 from Andrej Mitrovic 2011-05-24 17:11:28 PDT --- Btw, I think I know what you were referring to now. The opApply at line 1984 uses a delegate that takes a ref string. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059 --- Comment #8 from Steven Schveighoffer 2011-05-24 17:08:24 PDT --- I think this was a D1 module "casted" to D2 to get it to compile :) Probably would be better served reimplemented, but obviously someone would have to spend some quality time doing that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059 --- Comment #7 from Andrej Mitrovic 2011-05-24 16:57:25 PDT --- Actually there's 4 opApply implementations in that module and each of them is casting char[] to a string. And other methods like getKeyName, getValueName, etc.. seem to do the same thing. Ugly! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059 --- Comment #6 from Andrej Mitrovic 2011-05-24 16:53:41 PDT --- Yeah from a quick glance at the registry module it does seem a little fishy overall. __gshared variables, ASCII-only WinAPI calls (what if the registry key is in UTF, if that's possible?), casts to strings.. maybe this module needs to be refactored. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059 --- Comment #5 from Steven Schveighoffer 2011-05-24 15:28:28 PDT --- I completely misunderstood the problem here, I thought the string was being directly returned in the opApply delegate, not a Key object. Yes, I agree, the string should be idup'd. Doing anything differently would require a redesign (which I think actually is in order, to allocate that much data to do a simple loop is incredibly wasteful), but since nobody is owning this, your solution is as good as we can get for now. Sorry for the noise. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059 --- Comment #4 from Andrej Mitrovic 2011-05-24 15:12:35 PDT --- Change what exactly to const(char[])? You probably mean my "name" variable in the example code. I think this is again that issue of implicitly reusing a variable in a foreach loop. I really wish this was more explicit instead of relying on documentation, e.g. I'd love it if it were like this: foreach (ref buffer; iterator()) { } // it's reusing buffer on each iteration foreach (buffer; iterator()) { } // allocates new buffer on each iteration Maybe it's easy to reason about the current foreach mechanism when you only have one foreach loop. But when you have multiple foreach statements intertwined with dozens of different lines it's easy to miss that you should have duped something. It took me a good while before I realized what was wrong with my code until I ran it down to a simple test case like in the original post. I simply thought "hey, I'm assigning an immutable string to an immutable string, what could go wrong?". But this is more worthy of a post in the NG then to discuss it in here I guess.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059 --- Comment #3 from Steven Schveighoffer 2011-05-24 14:44:26 PDT --- I think the better solution is to change it to const(char)[]. This better reflects that the data may be changing between iterations. If you are not storing the strings from this, then it is extremely wasteful to allocate a new memory block for each iteration. You can always idup or dup if you want to. Note, I think the documentation needs to specifically state it reuses the buffer, so you should .dup or .idup if you wish to keep the data beyond the loop iteration. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059 --- Comment #2 from Andrej Mitrovic 2011-05-24 14:36:34 PDT --- Should I just change that line to: Key key = m_key.getKey(sName[0 .. cchName].idup); I think this makes the most sense if we're to trust that strings are immutable. I can make a pull request if this fix would be ok (my tests show that this fixes the issue). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6054] [CTFE] ICE when returning a returned compile-time associative array containing a key of an idup-ed array literal
http://d.puremagic.com/issues/show_bug.cgi?id=6054 kenn...@gmail.com changed: What|Removed |Added Severity|normal |regression --- Comment #1 from kenn...@gmail.com 2011-05-24 13:18:59 PDT --- (Marking as 'regression', as the bug doesn't appear in 2.052.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6054] New: [CTFE] ICE when returning a returned compile-time associative array containing a key of an idup-ed array literal
http://d.puremagic.com/issues/show_bug.cgi?id=6054 Summary: [CTFE] ICE when returning a returned compile-time associative array containing a key of an idup-ed array literal Product: D Version: D2 Platform: Other OS/Version: Mac OS X Status: NEW Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: kenn...@gmail.com --- Comment #0 from kenn...@gmail.com 2011-05-24 13:18:12 PDT --- Test case: - enum x = { auto p = { int[string] pieces; pieces[['a'].idup] = 1; return pieces; }(); return p; }(); - Bus error - Stack trace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x 0xacbb in ArrayLiteralExp::implicitConvTo (this=0x345140, t=0x30cc10) at cast.c:524 524Type *typeb = type->toBasetype(); (gdb) bt #0 0xacbb in ArrayLiteralExp::implicitConvTo (this=0x345140, t=0x30cc10) at cast.c:524 #1 0xac80 in AssocArrayLiteralExp::implicitConvTo (this=0x3451a0, t=0x310800) at cast.c:558 #2 0xc37d in Expression::implicitCastTo (this=0x3451a0, sc=0x344c30, t=0x310800) at cast.c:32 #3 0x000b97b4 in ExpInitializer::semantic (this=0x310d20, sc=0x344c30, t=0x310800, needInterpret=4) at mars.h:770 #4 0x00057c69 in VarDeclaration::semantic2 (this=0x310d30, sc=0x344c30) at declaration.c:1395 #5 0x000c87f2 in Module::semantic2 (this=0x30feb0) at module.c:829 #6 0x000c6268 in main (argc=5, argv=0x30ad70) at mars.c:1208 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6053] New: [CTFE] Two ICEs involving pointers (dereference and assign; pointer variable on stack)
http://d.puremagic.com/issues/show_bug.cgi?id=6053 Summary: [CTFE] Two ICEs involving pointers (dereference and assign; pointer variable on stack) Product: D Version: D2 Platform: Other OS/Version: Mac OS X Status: NEW Keywords: ice-on-invalid-code Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: kenn...@gmail.com --- Comment #0 from kenn...@gmail.com 2011-05-24 11:37:43 PDT --- Test case 1: static assert({ int* a; return true; }()); Assertion failed: (isStackValueValid(newval)), function createStackValue, file interpret.c, line 4070. Abort trap Test case 2: static assert({ int a; *(&a) = 0; return true; }()); CTFE internal error: unsupported assignment *& a = 0 Assertion failed: (e1->op == TOKarraylength || e1->op == TOKvar || e1->op == TOKdotvar || e1->op == TOKindex || e1->op == TOKslice), function interpretAssignCommon, file interpret.c, line 2380. Abort trap (In 2.052 this simply result in a "cannot evaluate" error, not an ICE.) A related test case of #2 would be static assert({ int a, b, c; (c ? a : b) = 1; return true; }()); This causes an ICE because (c ? a : b) is rewritten to *(c ? &a : &b). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5914] std.range.ElementType has duplicated unittest, ElementEncodingType is missing one
http://d.puremagic.com/issues/show_bug.cgi?id=5914 --- Comment #1 from Andrej Mitrovic 2011-05-24 11:18:05 PDT --- Looks like this was fixed on github, but no mention by who. Oh well.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6051] struct declarations allow a trailing semicolon
http://d.puremagic.com/issues/show_bug.cgi?id=6051 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from bearophile_h...@eml.cc 2011-05-24 10:22:13 PDT --- On the other hand I remember Andrei saying something about empty statements. Currently you can't write for(); I think he was looking for more uniformity. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6049] [CTFE]: Array literals of structs with invariant() are wrong
http://d.puremagic.com/issues/show_bug.cgi?id=6049 --- Comment #3 from Jonathan M Davis 2011-05-24 10:11:43 PDT --- Then I won't worry about it :). Invariants have been a source of trouble with std.datetime though and appear to be an area in the language implementation that still has some warts. IIRC, it caused some issues with purity initially (though we can now have pure invarians fortunately), and bug# 5058 has caused definite issues as well (hence why SysTime's invariant is commented out). Well, as annoying as such bugs are, at least we're running into them so that we can fix them. Thanks for looking into this one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6052] [CTFE] Structs elements in an array are treated like reference type
http://d.puremagic.com/issues/show_bug.cgi?id=6052 kenn...@gmail.com changed: What|Removed |Added Severity|normal |regression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6052] [CTFE] Structs elements in an array are treated like reference type
http://d.puremagic.com/issues/show_bug.cgi?id=6052 --- Comment #1 from kenn...@gmail.com 2011-05-24 09:10:47 PDT --- Note: the last 2 asserts refer to the case when the line 'el.a = i + 2;' is commented out. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6052] New: [CTFE] Structs elements in an array are treated like reference type
http://d.puremagic.com/issues/show_bug.cgi?id=6052 Summary: [CTFE] Structs elements in an array are treated like reference type Product: D Version: D2 Platform: Other OS/Version: Mac OS X Status: NEW Keywords: wrong-code Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: kenn...@gmail.com --- Comment #0 from kenn...@gmail.com 2011-05-24 09:06:57 PDT --- Test case: -- struct Bug6052 { int a; } bool bug6052() { Bug6052[2] arr; for (int i = 0; i < 2; ++ i) { Bug6052 el = {i}; Bug6052 ek = el; arr[i] = el; el.a = i + 2; assert(ek.a == i); // ok assert(arr[i].a == i); // fail } assert(arr[1].a == 1); // ok assert(arr[0].a == 0); // fail return true; } static assert(bug6052()); -- x.d(16): Error: assert(arr[cast(uint)i].a == i) failed x.d(23): Error: cannot evaluate bug6052() at compile time x.d(23): Error: static assert (bug6052()) is not evaluatable at compile time -- Setting a struct value on a array should perform a bit-copy, so modifying 'el' should not affect 'arr[i]', but currently CTFE does it wrongly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5954] [CTFE] enum structs with ctor
http://d.puremagic.com/issues/show_bug.cgi?id=5954 kenn...@gmail.com changed: What|Removed |Added CC||kenn...@gmail.com OS/Version|Windows |All --- Comment #1 from kenn...@gmail.com 2011-05-24 08:12:57 PDT --- A workaround is to construct it in a delegate. --- struct Foo { int x; this(int xx) { this.x = xx * 6; } } void main() { enum f = { return Foo(10); }(); static assert(f.x == 60); } --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
http://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #44 from Matt Peterson 2011-05-24 08:00:56 PDT --- Nevermind, I am seeing the second line of dashes, I was just getting confused at the difference between Throwable.toString and the way the runtime prints it out when it's unhandled. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6051] struct declarations allow a trailing semicolon
http://d.puremagic.com/issues/show_bug.cgi?id=6051 Bernard Helyer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Bernard Helyer 2011-05-24 06:25:45 PDT --- Empty declaration. Derp. Nevermind. ;; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6051] New: struct declarations allow a trailing semicolon
http://d.puremagic.com/issues/show_bug.cgi?id=6051 Summary: struct declarations allow a trailing semicolon Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: blood.of.l...@gmail.com --- Comment #0 from Bernard Helyer 2011-05-24 06:23:42 PDT --- struct A { int foo; }; DMD allows this. This is not mentioned in the documentation. One or the other is incorrect. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6049] [CTFE]: Array literals of structs with invariant() are wrong
http://d.puremagic.com/issues/show_bug.cgi?id=6049 --- Comment #2 from Don 2011-05-24 00:41:06 PDT --- (In reply to comment #1) > So, as a temporary fix to make the autotester is passing, commenting out the > invariants should fix the problem? Yes, but I already have a DMD pull request that fixes the problem . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---