[Issue 4860] Taking delegates to a member function broken if method is also aliased in from a base class
http://d.puremagic.com/issues/show_bug.cgi?id=4860 --- Comment #7 from Don 2010-11-19 22:16:42 PST --- That patch was a bit too early in the function. Should be e2ir.c, line 3308. Still in DelegateExp::toElem(). { // Get pointer to function out of virtual table unsigned vindex; assert(ethis); ep = el_same(ðis); ep = el_una(OPind, TYnptr, ep); vindex = func->vtblIndex; +if (vindex < 0) +error("Internal compiler error: malformed delegate. See Bugzilla 4860"); // Build *(ep + vindex * 4) ep = el_bin(OPadd,TYnptr,ep,el_long(TYsize_t, vindex * 4)); ep = el_una(OPind,TYnptr,ep); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5244] PATCH: fix use of uninitialised variable in toObj.c
http://d.puremagic.com/issues/show_bug.cgi?id=5244 Brad Roberts changed: What|Removed |Added Attachment #822|application/octet-stream|text/plain mime type|| Attachment #822 is|0 |1 patch|| -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5244] New: PATCH: fix use of uninitialised variable in toObj.c
http://d.puremagic.com/issues/show_bug.cgi?id=5244 Summary: PATCH: fix use of uninitialised variable in toObj.c Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: minor Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: s.d.hamm...@googlemail.com --- Comment #0 from simon 2010-11-19 16:20:39 PST --- Created an attachment (id=822) PATCH: fix use of uninitialised variable in toObj.c As summary: triggered by test\compilable\header.d, line 135. pretty minor, but the affected codes needs a look at JIC -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5243] New: dmd -run potentially removes user files
http://d.puremagic.com/issues/show_bug.cgi?id=5243 Summary: dmd -run potentially removes user files Product: D Version: D1 & D2 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: llu...@gmail.com --- Comment #0 from Leandro Lucarella 2010-11-19 16:09:43 PST --- See this example: $ mkdir x $ echo 'void main() {}' > x/test.d $ echo "my very important data that shouldn't be ereased" > test $ ls test test $ cat test my very important data that shouldn't be ereased $ dmd -run x/test.d $ ls test ls: cannot access test: No such file or directory $ cat test cat: test: No such file or directory I think this is a very serious bug. It's really unexpected that DMD removes the test file (I can understand why it happens, but it shouldn't). test.d being in another directory is just to point how much surprising could be that running a "script" in an unrelated directory removes files in the current directory. If DMD wants to put D in the scripting world, this should be fixed ASAP, as no scripting language EVER will remove your files unexpectedly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 Michal Minich changed: What|Removed |Added CC||michal.min...@gmail.com --- Comment #6 from Michal Minich 2010-11-19 15:39:03 PST --- both @nogc and @noheap are very usefull, and I would like to have them available. @nogc being less strict - allowing for manual memory management. I think that both these attributes should be processed by some other tool. Performance considerations are not usually part of the language, but are common as third party solutions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2095] covariance w/o typechecks = bugs
http://d.puremagic.com/issues/show_bug.cgi?id=2095 --- Comment #22 from Bruno Medeiros 2010-11-19 15:31:03 PST --- > Yes, like I mentioned, Steven's solution has some limitations. I meant Stewart (Gordon), not Steven. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2095] covariance w/o typechecks = bugs
http://d.puremagic.com/issues/show_bug.cgi?id=2095 --- Comment #21 from Bruno Medeiros 2010-11-19 15:29:24 PST --- (In reply to comment #20) > (In reply to comment #19) > > > Classes are not like arrays and pointers. These are > > supposed to be lightweight data types, it's out of place for D to have that > > extra runtime data in these lightweight data types (arrays and pointers). It > > worries me that you suggested this change without even considering an > > approach > > based on fixing/improving the (static) type system. > > A solution based on the type system (plus a bit of syntax) as in C#/Java seems > better. But it's probably better to implement it after the current group of > features is implemented. Yes, like I mentioned, Steven's solution has some limitations. For example, if you have B[] the best you have is being allowed to cast it to const(A)[]. But that means you wont be able to call mutable methods on the elements of that array, whereas with a wildcard type such as: [] you would be able to call mutable methods of A. So this solution is not perfect, but it works with existing concepts in D (it only needs const), whereas we are far away from the point where can add such disrupting and complex features such as wildcard type. (D's type system seems to be struggling already as it is) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2056] Const system does not allow certain safe casts/conversions involving deep composite types
http://d.puremagic.com/issues/show_bug.cgi?id=2056 --- Comment #6 from Bruno Medeiros 2010-11-19 15:20:41 PST --- (In reply to comment #5) > > When this bug was submitted, the lines marked with "// Error here" did not > > compile > > So what does the fix for bug 3621, I wonder? (It's for dmd 2.038) I don't know. The code sample in #3621 still compiles ok, so maybe it was a mistake from Walter's part, and the bug is not really fixed. Just like #2544 is not fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5027] Ghost fields for Contract Programming
http://d.puremagic.com/issues/show_bug.cgi?id=5027 --- Comment #3 from Bruno Medeiros 2010-11-19 15:11:32 PST --- If instead of: @ghost static int x; you have: debug(contracts) static int x; and "contracts" is said identifier that is only defined in non-release mode, then the compiler can enforce those constraints equally well: Just compile it in release and see if it compiles without errors or not. It might be a minor drawback in compiling performance (if you need to compile twice), but it is not any less of a drawback on compiler checking power. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5242] self referencing template constraint crashes compiler
http://d.puremagic.com/issues/show_bug.cgi?id=5242 Don changed: What|Removed |Added Keywords||ice-on-invalid-code, patch CC||clugd...@yahoo.com.au --- Comment #1 from Don 2010-11-19 14:42:41 PST --- PATCH: template.c, line 2509 void deduceBaseClassParameters(BaseClass *b, Scope *sc, Type *tparam, TemplateParameters *parameters, Objects *dedtypes, Objects *best, int &numBaseClassMatches) { -TemplateInstance *parti = b->base->parent->isTemplateInstance(); +TemplateInstance *parti = b->base ? b->base->parent->isTemplateInstance() : NULL; if (parti) { // Make a temporary copy of dedtypes so we don't destroy it Objects *tmpdedtypes = new Objects(); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5242] New: self referencing template constraint crashes compiler
http://d.puremagic.com/issues/show_bug.cgi?id=5242 Summary: self referencing template constraint crashes compiler Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: michal.min...@gmail.com --- Comment #0 from Michal Minich 2010-11-19 14:30:59 PST --- I wanted to restrict template parameter X to allow only derived classes of A. class A (X : A!(X)) { } class B : A!(B) { } void main () {} -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5240] Faster std.random.uniform() for [0.0, 1.0) range
http://d.puremagic.com/issues/show_bug.cgi?id=5240 --- Comment #1 from bearophile_h...@eml.cc 2010-11-19 12:10:42 PST --- A specialized overload/function like this is useful in Phobos even if it's not faster. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5121] Make std.algorithm.swap weakly pure
http://d.puremagic.com/issues/show_bug.cgi?id=5121 --- Comment #1 from bearophile_h...@eml.cc 2010-11-19 10:05:01 PST --- See: http://www.dsource.org/projects/phobos/changeset/2180 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4122] More handy BigInt.toString()
http://d.puremagic.com/issues/show_bug.cgi?id=4122 --- Comment #1 from bearophile_h...@eml.cc 2010-11-19 10:06:24 PST --- See: http://www.dsource.org/projects/phobos/changeset/2183 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5103] Container Documentation missing syntax
http://d.puremagic.com/issues/show_bug.cgi?id=5103 --- Comment #5 from Nick Treleaven 2010-11-19 09:45:51 PST --- > It's defined in docsrc/std.ddoc, but not in phobos/std.ddoc I can confirm that building with docsrc/std.ddoc fixes this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5027] Ghost fields for Contract Programming
http://d.puremagic.com/issues/show_bug.cgi?id=5027 --- Comment #2 from bearophile_h...@eml.cc 2010-11-19 09:45:30 PST --- (In reply to comment #1) > Or alternatively, have the compiler define a debug/version identifier when > compiled in release mode, and then just use conditional compilation. In that case the compiler can't enforce this constraint: > can't be accessed inside static or instance methods of the > class/struct/union, The idea is that ghost field may be read/written only inside pre/post-conditions and invariants. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5193] SList cannot have struct elements that have immutable members.
http://d.puremagic.com/issues/show_bug.cgi?id=5193 chuck changed: What|Removed |Added CC||chuck.so...@gmail.com --- Comment #1 from chuck 2010-11-19 09:35:14 PST --- WARNING: N00B ALERT! Similar issues with Array and/or SList initializer? Similar but slightly different: main.d import std.container; void main() { auto aList = Array!string(); } Result $ dmd -run main /opt/dmd2/bin/../../src/phobos/std/container.d(1536): Error: this for _data needs to be type Array not type Payload /opt/dmd2/bin/../../src/phobos/std/container.d(1537): Error: this for _data needs to be type Array not type Payload /opt/dmd2/bin/../../src/phobos/std/container.d(1538): Error: this for _data needs to be type Array not type Payload Different but slightly similar: main.d import std.container; void main() { auto s = SList!string("hello"); } Result $ dmd -run main main.d(5): Error: template std.container.SList!(string).SList.__ctor(U) if (isImplicitlyConvertible!(U,T)) does not match any function template declaration main.d(5): Error: template std.container.SList!(string).SList.__ctor(U) if (isImplicitlyConvertible!(U,T)) cannot deduce template function from argument types !()(string) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5027] Ghost fields for Contract Programming
http://d.puremagic.com/issues/show_bug.cgi?id=5027 Bruno Medeiros changed: What|Removed |Added CC||bdom.pub+deeb...@gmail.com --- Comment #1 from Bruno Medeiros 2010-11-19 09:36:07 PST --- Or alternatively, have the compiler define a debug/version identifier when compiled in release mode, and then just use conditional compilation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly.
http://d.puremagic.com/issues/show_bug.cgi?id=2043 Bruno Medeiros changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #5 from Bruno Medeiros 2010-11-19 08:59:46 PST --- *** Issue 4966 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4966] Loops and closures break immutable
http://d.puremagic.com/issues/show_bug.cgi?id=4966 Bruno Medeiros changed: What|Removed |Added Status|NEW |RESOLVED CC||bdom.pub+deeb...@gmail.com Resolution||DUPLICATE --- Comment #1 from Bruno Medeiros 2010-11-19 08:59:45 PST --- There is not just one variable 'v', there are several "instances" of variable 'v', each of them created on each iteration of the loop. Each of them is immutable during its lifecycle (and cease to exist after their lifecycle, by definition). The orthogonal solution is: * make each 'v' variable be heap-allocated (have unscoped lifecycle). This is consistent to how variables work in the top scope in functions. I'm starting to reconsider though, if closures should automatically make variables be heap-allocated. Maybe its best to require a keyword/annotation in such referenced variables, and make the code not compile if such keywords is not present. *** This issue has been marked as a duplicate of issue 2043 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5241] dmd: ABI breakage/regression
http://d.puremagic.com/issues/show_bug.cgi?id=5241 nfx...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #2 from nfx...@gmail.com 2010-11-19 08:45:57 PST --- Lazy patch: diff --git a/idgen.c b/idgen.c index 023d8a9..c0cfc0b 100644 --- a/idgen.c +++ b/idgen.c @@ -232,6 +232,8 @@ Msgtable msgtable[] = // varargs implementation { "va_argsave_t", "__va_argsave_t" }, { "va_argsave", "__va_argsave" }, + +{ "m_align" }, }; diff --git a/typinf.c b/typinf.c index 906795a..ab9d87b 100644 --- a/typinf.c +++ b/typinf.c @@ -593,8 +593,11 @@ void TypeInfoStructDeclaration::toDt(dt_t **pdt) // uint m_flags; dtdword(pdt, tc->hasPointers()); -// uint m_align; -dtdword(pdt, tc->alignsize()); +if (Type::typeinfostruct->search(NULL, Id::m_align, 0)) +{ +// uint m_align; +dtdword(pdt, tc->alignsize()); +} #if DMDV2 // xgetMembers -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5241] dmd: ABI breakage/regression
http://d.puremagic.com/issues/show_bug.cgi?id=5241 --- Comment #1 from nfx...@gmail.com 2010-11-19 08:20:24 PST --- (In reply to comment #0) > At some point, both dmd and Phobos1 added a new member to TypeInfo_Struct: > m_flags. Damn, that should be m_align. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5241] New: dmd: ABI breakage/regression
http://d.puremagic.com/issues/show_bug.cgi?id=5241 Summary: dmd: ABI breakage/regression Product: D Version: D1 Platform: Other OS/Version: All Status: NEW Severity: regression Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: nfx...@gmail.com --- Comment #0 from nfx...@gmail.com 2010-11-19 08:19:30 PST --- At some point, both dmd and Phobos1 added a new member to TypeInfo_Struct: m_flags. The way dmd handles this causes an ABI breakage: dmd will use the _calculated_ size of the struct to calculate the offset of the name string. After that, dmd _unconditionally_ writes the new m_flags field, and writes it at the same offset where the name string is supposed to start. As a result, TypeInfo names for structs are broken. The first 4 items of typeid(somestruct).toString() will contain garbage. I'm not really sure why after these 4 bytes, the expected string starts. Either I got it wrong, or the backend data segment writer does strange things? The problem doesn't appear if the object.d[i] contains the proper m_align. E.g. compare: http://www.dsource.org/projects/phobos/browser/branches/phobos-1.x/phobos/object.d#L141 http://www.dsource.org/projects/tango/browser/trunk/object.di#L163 (WARNING: BSD LICENSED CODE) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 SHOO changed: What|Removed |Added CC||zan77...@nifty.com --- Comment #5 from SHOO 2010-11-19 07:17:10 PST --- I agree this suggestion. This is not only performance but also behavior. When GC runs, it is a very huge cause of trouble to lack in real-time processing. All programs may not work under the abundant resources. There are software that put emphasis on point that should work in limited resource and limited duration like embedded software. There are software that cannot offer performance to be satisfied with if they don't control it by a high-speed period of 1,000Hz like haptic device controlling. There are software to control the medical device that the delay of moment takes the human life. It is fatal to lack in this property. Of course it will be impossible to encode not to use GC at all. In that case, you may move processing to another thread that never use GC. It is not important that a heap is assigned, and it is important that GC does not work. Therefore I prefer "@nogc" to @noheap. On the other hand, there is a problem of the readability. It does not appear on the code even if I introduced a profile to observe a behavior of the real-time processing. The property is clear if @nogc/@noheap is given to the attribute of the function. It is the best that the thing which wants not to be compiled is not compiled. And I think it to be the information that a compiler can grasp like nothrow. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5240] New: Faster std.random.uniform() for [0.0, 1.0) range
http://d.puremagic.com/issues/show_bug.cgi?id=5240 Summary: Faster std.random.uniform() for [0.0, 1.0) range Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-11-19 07:16:51 PST --- std.random.uniform() is a powerful and flexible function, but some tests show that it's slow. It also calls nextafter() that is not fast. A very common use case is the generation of random doubles in the [0.0, 0.1[ range (open on the right). So I suggest to speed up this special case. This special case is present in the Python standard module "random" too, it is just named random(). A way to support it is just to add a uniform() that takes no arguments (and hopefully it doesn't need to call nextafter() inside): import std.random: uniform; void main() { double d = uniform(); // equivalent to uniform(0.0, 1.0) but faster } This function that takes no arguments may also have a name like "uniform01()" or "random()". Another special case that may be worth supporting is the generation of a random size_t. This is useful because it avoids using floating point values at all, and probably minimizes other operations too to generate it, so it may be faster still than the uniform() with no arguments. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5231] BigInt lacks a normal toString()
http://d.puremagic.com/issues/show_bug.cgi?id=5231 --- Comment #17 from bearophile_h...@eml.cc 2010-11-19 07:14:29 PST --- (In reply to comment #16) > This is a bug in format. Even the partial fix I made for bug 5237, makes > BigInt > print correctly, without any change to the BigInt code. > > *** This issue has been marked as a duplicate of issue 5237 *** See also: http://d.puremagic.com/issues/show_bug.cgi?id=4122 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2954] [tdpl] Appalling bug in associative arrays (D2 only)
http://d.puremagic.com/issues/show_bug.cgi?id=2954 --- Comment #5 from Don 2010-11-19 06:36:06 PST --- (In reply to comment #4) > The fix still isn't right, as it fails at compile time on line 10. It works for me. Hmm. I think this might also be relying on the patch for bug 5218, which I still have active in my local copy. Sorry about that -- it needs to be included as well. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5238] PATCH: fix return of uninitialised var in interpret.c
http://d.puremagic.com/issues/show_bug.cgi?id=5238 --- Comment #4 from simon 2010-11-19 06:21:24 PST --- (In reply to comment #1) > With this patch applied on my system, I still fail to pass > runnable/interpret.d > with -O, but now a few lines later at 2110: > > 2106 int goodfoo3() > 2107 { > 2108S[4] w = void; // uninitialized array of structs > 2109w[$-2].x = 217; // initialize one member > 2110return w[2].x; > 2111 } > 2112 static assert(goodfoo3()==217); > > Simon, did you find this due to a failure with no changes to interpret.d or > with -O added to the set of compilation flags to test? Neither. I've build DMD with Visual studio; the vc compiler does a pretty good job of detected these sorts of bugs in debug builds. I'll run the rest of the tests when I get home, see if there are any other gotchas lurking. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 --- Comment #6 from Lars T. Kyllingstad 2010-11-19 04:35:04 PST --- (In reply to comment #3) > (In reply to comment #1) > > Partial fix in svn 2183. This fixes the last 3 cases, not the first one. > > It would be very straightforward to implement the first case, but we need to > > think if it would really be a sensible design, since we'd be doing > > atoi(itoa(atoi(original_string))). > > Couln't that be easily solved by storing the full format string in FormatSpec? One problem is of course when the user passes a non-immutable format string, as in char[] fmt = "%s %s".dup; writefln(fmt, 1, 3.14); Then each format specifier has to be dup-ed before being stored in FormatSpec. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 --- Comment #5 from Lars T. Kyllingstad 2010-11-19 04:32:21 PST --- (In reply to comment #4) > My guess is that positional parameters will make it more complicated, > but possibly it's really simple. Regarding positional parameters, allow me to restate a point I made in the DIP9 thread on the newsgroup: I think it's best to leave out the '%' from the format string that is sent to toString(). This will facilitate the use of positional parameters, in which the percent is followed by a position specifier which necessarily has to be handled at a higher level than toString(). Example: BigInt i = "456"; BigInt j = "123"; writefln("%2$s %1$s", i, j); // Prints "123 456" The only thing BigInt.writeTo() needs to see is the part after the '$' character. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 --- Comment #4 from Don 2010-11-19 04:19:11 PST --- (In reply to comment #3) > (In reply to comment #1) > > Partial fix in svn 2183. This fixes the last 3 cases, not the first one. > > It would be very straightforward to implement the first case, but we need to > > think if it would really be a sensible design, since we'd be doing > > atoi(itoa(atoi(original_string))). > > Couln't that be easily solved by storing the full format string in FormatSpec? Probably. My guess is that positional parameters will make it more complicated, but possibly it's really simple. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 Lars T. Kyllingstad changed: What|Removed |Added CC||bugzi...@kyllingen.net --- Comment #3 from Lars T. Kyllingstad 2010-11-19 02:26:47 PST --- (In reply to comment #1) > Partial fix in svn 2183. This fixes the last 3 cases, not the first one. > It would be very straightforward to implement the first case, but we need to > think if it would really be a sensible design, since we'd be doing > atoi(itoa(atoi(original_string))). Couln't that be easily solved by storing the full format string in FormatSpec? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 Don changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Don 2010-11-19 01:27:43 PST --- *** Issue 5231 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5231] BigInt lacks a normal toString()
http://d.puremagic.com/issues/show_bug.cgi?id=5231 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #16 from Don 2010-11-19 01:27:43 PST --- This is a bug in format. Even the partial fix I made for bug 5237, makes BigInt print correctly, without any change to the BigInt code. *** This issue has been marked as a duplicate of issue 5237 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 --- Comment #1 from Don 2010-11-19 01:25:33 PST --- Partial fix in svn 2183. This fixes the last 3 cases, not the first one. It would be very straightforward to implement the first case, but we need to think if it would really be a sensible design, since we'd be doing atoi(itoa(atoi(original_string))). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---