[Issue 5231] BigInt lacks a normal toString()
http://d.puremagic.com/issues/show_bug.cgi?id=5231 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2010-11-18 00:03:42 PST --- That's not really the correct solution. BigInt should act like an int. Specifically, BigInt b; writefln( b = %d, %x, b, b); should just work. This issue cannot be resolved until the definition of toString() is changed. void toString() is a fundamentally broken design. It's wrong on many levels. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5233] New: [patch] std.range.put accepts *any* element type when putting to an array.
http://d.puremagic.com/issues/show_bug.cgi?id=5233
Summary: [patch] std.range.put accepts *any* element type when
putting to an array.
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: sandf...@jhu.edu
--- Comment #0 from Rob Jacques sandf...@jhu.edu 2010-11-18 00:13:49 PST ---
Essentially, there is a lack of a static assert in some of the branches of the
put function, leading to any element being accepted for certain input ranges
(notably strings) which define a non-assignable 'front'. Unfortunately, ding
template constraints result in a recursive expansion with isOutputRange. I've
listed a patch below which adds the static asserts and special cases strings so
they work as expected. Oh, here's a simple unit test:
assert( !isOutputRange!(char[],real) );
Patch:
void put(R, E)(ref R r, E e) { // BUG, adding template constraints result in a
recursive expansion with isOutputRange
static if ( __traits(compiles, {return R.init.put(E.init);}) ) { // Patch
from Issue 4880
// commit to using the put method
static if (!isArray!R is(typeof(r.put(e {
r.put(e);
} else static if (!isArray!R is(typeof(r.put((e)[0..1] {
r.put((e)[0..1]);
} else {
static assert(false, Cannot put a ~E.stringof~ into a
~R.stringof);
}
} else {
static if (isInputRange!R) {
// Commit to using assignment to front
static if (is(typeof(r.front = e, r.popFront( {
r.front = e;
r.popFront();
} else static if (isInputRange!E is(typeof(put(r, e.front {
for (; !e.empty; e.popFront()) put(r, e.front);
} else static if( isSomeString!R isSomeChar!E ) {
static if( (typeof(r[0])).sizeof E.sizeof ) {
// must do some transcoding around here to support
char[].put(dchar)
Unqual!(typeof(r[0]))[(typeof(r[0])).sizeof == 1 ? 4 : 2]
encoded;
auto len = std.utf.encode(encoded, e);
writeln( typeof(encoded).stringof,\t, typeof(r[0]).sizeof
,\t, E.sizeof );
foreach(c;encoded[0 .. len]) {
r[0] = c;
r.popFront;
}
} else {
r[0] = e;
r.popFront;
}
} else {
static assert(false, Cannot put a ~E.stringof~ into a
~R.stringof);
}
} else {
// Commit to using opCall
static if (is(typeof(r(e {
r(e);
} else static if (is(typeof(r((e)[0..1] {
r((e)[0..1]);
} else {
static assert(false, Cannot put a ~E.stringof~ into a
~R.stringof);
}
}
}
}
--
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 #3 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-18 00:24:35 PST --- void toString()? Normally, it's string toString(). The only problem that I'm aware of with regards to toString() design at the moment is the fact that it must be _exactly_ string toString() and can't be const or pure or whatnot. I don't see why BigInt can't just have a normal toString() which returns a string representation of BigInt. Having a fancier toString() like it does now may be useful, but I don't see how it precludes having a normal toString(). -- 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 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #4 from nfx...@gmail.com 2010-11-18 00:56:03 PST --- (In reply to comment #2) void toString() is a fundamentally broken design. It's wrong on many levels. But it allows more control over formatting and potentially reduces memory allocation. string toString() seems more broken to me: no control, forces you to do memory allocation. (Another broken design issue is that _all_ objects in D have a toString() method, even if it doesn't make sense, but that is off-topic here.) What is worrying is that void toString is nowhere documented. Does std.format use it or what? -- 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 #5 from nfx...@gmail.com 2010-11-18 00:57:38 PST --- (In reply to comment #4) What is worrying is that void toString is nowhere documented. Does std.format use it or what? Should be: is it supposed to use it? Of course it doesn't right now. If it should, the bug report is about std.format/writefln, and not std.bigint. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.
http://d.puremagic.com/issues/show_bug.cgi?id=2834 Max Samukha samu...@voliacable.com changed: What|Removed |Added CC||samu...@voliacable.com --- Comment #8 from Max Samukha samu...@voliacable.com 2010-11-18 03:39:17 PST --- So what is the verdict? Should we simply specify that struct destructors are not automatically called except in RAII and remove the struct-in-class special case? BTW, there are other problems (serious IMO): auto ss = new S[10]; ss.length = 5; delete ss; Destructors are not called on the last 5 elements. auto ss = new S[10]; ss ~= ss; delete ss; We have a nasty problem when destructors are called on the appended elements because postblits was not run for them during append. etc Essentially, operations on arrays of structs with postblits/dtors defined are currently unusable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.
http://d.puremagic.com/issues/show_bug.cgi?id=2834 --- Comment #9 from Max Samukha samu...@voliacable.com 2010-11-18 03:59:12 PST --- (In reply to comment #8) We have a nasty problem when destructors are called on the appended elements because postblits was not run for them during append. I meant the problem is the destructors called on objects that have not been postblitted. -- 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 #4 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-18 04:06:29 PST --- A regression? Not exactly. When this bug was submitted, the lines marked with // Error here did not compile, and that was the bug that was reported. At some point DMD was changed so that the first, and later both code samples above compiled without errors. (I don't know if it was because Walter tried to fix this bug specifically, or if it was due to some other DMD changes). So this bug became fixed, but as I found after seeing #2544, this bug is actually invalid, and should not have been fixed in the first place. ( For curiosity, it would only be valid if immutable did not exist, or more precisely, if T was the only subtype of const(T) ) -- 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
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #6 from Steven Schveighoffer schvei...@yahoo.com 2010-11-18
05:10:23 PST ---
(In reply to comment #2)
That's not really the correct solution.
BigInt should act like an int. Specifically,
BigInt b;
writefln( b = %d, %x, b, b);
should just work.
This issue cannot be resolved until the definition of toString() is changed.
void toString() is a fundamentally broken design. It's wrong on many levels.
So BigInt's aren't printable via writeln in protest? I guess I don't
understand why you can't do this:
string toString()
{
string retval;
void sink(const(char)[] data) { retval ~= data; }
toString(sink, null);
return retval;
}
It doesn't hurt/limit the current toString, does it? And then it makes bigints
printable via writeln.
BTW, toString's delegate is not scope, so you are going to allocate a closure
for that...
--
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 #7 from Don clugd...@yahoo.com.au 2010-11-18 05:58:20 PST --- (In reply to comment #6) (In reply to comment #2) So BigInt's aren't printable via writeln in protest? Yes. I refuse to play any part in propagating the toString() abomination. BigInt will NEVER have a string toString() function. No frigging way. This needs to be fixed in writefln/format. -- 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 #8 from Steven Schveighoffer schvei...@yahoo.com 2010-11-18 06:30:23 PST --- Pardon me for saying so, but that's too short-sighted. first, it's not just a writeln/format change, it's a compiler change too. The compiler is the one who decides whether to store a function pointer to toString in the TypeInfo_Struct. Maybe you can help fix that... Second, it's they way things currently work. It's like saying you refuse to have const functions because they should be inout, but inout doesn't work. When toString is fixed, then you can remove the crufty function, and nobody cares whether it was ever there or not. It looks to the outside like phobos is immature when it can't even print its own types, regardless of how inefficient it is. Note that I 100% agree that the current system is crap, and needs to be completely redone similar to how you have implemented it, but it's not how it works now. Can't BigInt just play along and we can push for changes to the system without making the library look like a stubborn child? BTW, when the system is changed, I wouldn't want it to be called toString, since string may have nothing to do with it. I'd call it something like format or output. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5234] New: [qtd] AA element assignment should use copy-constructor to initialize new elements
http://d.puremagic.com/issues/show_bug.cgi?id=5234
Summary: [qtd] AA element assignment should use
copy-constructor to initialize new elements
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: samu...@voliacable.com
--- Comment #0 from Max Samukha samu...@voliacable.com 2010-11-18 08:23:00
PST ---
Currently opAssign is called on newly created AA elements of struct types. This
leaves us absolutely no possibility to properly initialize AA elements without
introducing costly and unreliable checks in opAssign:
struct QString
{
ref QString opAssign(ref QString other)
{
if (memcmp(cast(void*)this, cast(void*)T.init, sizeof(this)) == 0)
{
// construct copy
}
else
{
// assign
}
}
}
QString[int] ss;
QString s = qs(some string);
ss[0] = s;
Can AA be modified so that new elements are initialized with the
copy-constructor (as they should be) and not opAssign?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5234] [qtd] AA element assignment should use copy-constructor to initialize new elements
http://d.puremagic.com/issues/show_bug.cgi?id=5234 --- Comment #1 from Max Samukha samu...@voliacable.com 2010-11-18 08:37:19 PST --- T.init should be QString.init in the example -- 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 #19 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-18 11:10:49 PST --- I've looked at Stewart Gordon's proposal, and I agree that they are safe and sound (although it may need to be more detailed or cleaned-up a bit). I actually had prepared a post over a month ago detailing what is basically the same proposal and underlying conclusions as Stewart's proposal. I did it when I came across the code sample in bug #2544, but before I read Stewart's proposal (which I read only recently). I didn't actually post the text I prepared yet, since I was waiting to clear up my backlog of D newsgroups message. :S In any case, the conclusions are the same, especially to the point of realizing the connection to Java's wildcard generics (which, BTW, are the only way to express this use case safely, but without further loss of type system functionality). As a simple solution, I recommend we adopt Stewart's proposal, which is good enough I think. The very best solution would be to have a concept like Java's wildcard's, but that is too complex in implementation to consider any time soon. @bearophile: Some runtime data info may be added, then. There is already some of it for classes and modules. Are you out of your mind? 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5236] New: [patch] std.format.formattedRead/unformatValue does not support the raw reading of integer types
http://d.puremagic.com/issues/show_bug.cgi?id=5236
Summary: [patch] std.format.formattedRead/unformatValue does
not support the raw reading of integer types
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: sandf...@jhu.edu
--- Comment #0 from Rob Jacques sandf...@jhu.edu 2010-11-18 11:35:40 PST ---
The raw value reading code was never duplicated in the isIntegral version of
unformatValue. Given the amount of code overlap for raw value reading, I'd
recommend a re-factor of the unformatValue, but in the mean time, here is a
patch and unit test.
Unit test:
union B
{
char[int.sizeof] untyped;
int typed;
};
B b;
b.typed = 5;
char[] input = b.untyped[];
int witness;
formattedRead(input, %r, witness);
assert(witness == b.typed);
Patch:
/**
Reads an integral value and returns it.
*/
T unformatValue(T, Range, Char)(ref Range input, ref FormatSpec!Char spec)
if (isIntegral!T isInputRange!Range)
{
if (spec.spec == 'r')
{
// raw read
//enforce(input.length = T.sizeof);
enforce(isSomeString!Range || ElementType!(Range).sizeof == 1);
union X
{
ubyte[T.sizeof] raw;
T typed;
}
X x;
foreach (i; 0 .. T.sizeof)
{
static if (isSomeString!Range)
{
x.raw[i] = input[0];
input = input[1 .. $];
}
else
{
// TODO: recheck this
x.raw[i] = cast(ubyte) input.front;
input.popFront();
}
}
return x.typed;
}
enforce(std.algorithm.find(cdosuxX, spec.spec).length,
text(Wrong integral type specifier: `, spec.spec, '));
if (std.algorithm.find(dsu, spec.spec).length)
{
return parse!T(input);
}
assert(0, Parsing spec '~spec.spec~' not implemented.);
}
--
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 #11 from Don clugd...@yahoo.com.au 2010-11-18 12:01:39 PST --- (In reply to comment #10) (In reply to comment #9) If it was just a question of inefficiency, I would have implemented it. The issue is that it doesn't get the formatting string. So BigInt b; writefln(%x %+d, b, b); doesn't work, and cannot be made to work. But what about writeln, or writefln(%s...) ? Should those usages be excluded because you can't have custom formatting? Yes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5233] [patch] std.range.put accepts *any* element type when putting to an array.
http://d.puremagic.com/issues/show_bug.cgi?id=5233
--- Comment #1 from Rob Jacques sandf...@jhu.edu 2010-11-18 12:02:54 PST ---
An updated patch allowing char[]/wchar[] to be put into ubyte/ushort output
ranges.
void put(R, E)(ref R r, E e) { // BUG, adding template constraints result in a
recursive expansion with isOutputRange
static if ( __traits(compiles, {return R.init.put(E.init);}) ) { // Patch
from Issue 4880
// commit to using the put method
static if (!isArray!R is(typeof(r.put(e {
r.put(e);
} else static if (!isArray!R is(typeof(r.put((e)[0..1] {
r.put((e)[0..1]);
} else {
static assert(false, Cannot put a ~E.stringof~ into a
~R.stringof);
}
} else {
static if (isInputRange!R) {
// Commit to using assignment to front
static if (is(typeof(r.front = e, r.popFront( {
r.front = e;
r.popFront();
} else static if (isInputRange!E is(typeof(put(r, e.front {
pragma(msg,R,\t,E, =);
for (; !e.empty; e.popFront()) put(r, e.front);
} else static if( isSomeString!R isSomeChar!E ) {
static if( (typeof(r[0])).sizeof E.sizeof ) {
// must do some transcoding around here to support
char[].put(dchar)
Unqual!(typeof(r[0]))[(typeof(r[0])).sizeof == 1 ? 4 : 2]
encoded;
auto len = std.utf.encode(encoded, e);
writeln( typeof(encoded).stringof,\t, typeof(r[0]).sizeof
,\t, E.sizeof );
foreach(c;encoded[0 .. len]) {
r[0] = c;
r.popFront;
}
} else {
r[0] = e;
r.popFront;
}
} else static if(hasSlicing!E is(typeof(e.length == size_t))
is(typeof(put(r, e[0]))) ) {
for (; !e.empty; e = e[1..e.length]) put(r, e[0]);
} else {
static assert(false, Cannot put a ~E.stringof~ into a
~R.stringof);
}
} else {
// Commit to using opCall
static if (is(typeof(r(e {
r(e);
} else static if (is(typeof(r((e)[0..1] {
r((e)[0..1]);
} else {
static assert(false, Cannot put a ~E.stringof~ into a
~R.stringof);
}
}
}
}
--
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 #5 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-11-18 12:11:28 PST --- 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) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2544] implicit const casting rules allow violations of const-safety
http://d.puremagic.com/issues/show_bug.cgi?id=2544 --- Comment #12 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-11-18 12:15:53 PST --- Seems to be a regression, since according to bug 2056, this code didn't compile in dmd 2.013. -- 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 #12 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-18 12:31:36 PST --- So, you don't want writeln(bi); or to!string(bi) to work? I would think that ideally, BigInt would work exactly the same way that integers do. to!string(i) - decimal writeln(i) - decimal writefln(%s, i) - decimal writefln(%d, i) - decimal writefln(%f, i) - hex So, ideally, BigInt would do the same: to!string(bi) - decimal writeln(bi) - decimal writefln(%s, bi) - decimal writefln(%d, bi) - decimal writefln(%f, bi) - hex But you only want this?: writefln(%d, bi) - decimal writefln(%f, bi) - hex Okay. I can see an argument for a better handling of toString() in general (I'd never even heard anyone complain about string toString() or discuss the possibility of a void toString() before the discussion on this bug report) and that to!string(), writeln(), writefln(), etc. need to be fixed to support a void toString() instead of string toString(), but I don't understand why you would refuse to allow for BigInt to be convertible to a string or printed as one without a format string. I don't see why it shouldn't act the same way that all of the built-in integral values do in this regard. -- 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 #13 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-18 12:33:01 PST --- Whoops. I meant %x, not %f for hex. Sorry about that. -- 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 #20 from bearophile_h...@eml.cc 2010-11-18 12:38:47 PST --- (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. -- 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
--- Comment #4 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-11-18
12:40:40 PST ---
(In reply to comment #1)
No.
Use a profiler.
I compiled this code with profiler
---
class A
{
int delegate() a;
}
A f()
{
int a=1;
int g()
{
a+=3;
return a;
}
A b=new A();
b.a=g;
a+=2;
return b;
}
int main()
{
assert(f().a()==6);
return 0;
}
---
It gave me this output:
--
1__Dmain
_D4test1fFZC4test1A178017801
--
1__Dmain
_D4test1fFZC4test1A1gMFZi11616
--
__Dmain091391322
1_D4test1fFZC4test1A
1_D4test1fFZC4test1A1gMFZi
Timer Is 200032 Ticks/Sec, Times are in Microsecs
Num TreeFuncPer
CallsTimeTimeCall
1 3 3 3 _D4test1fFZC4test1A
1 4 0 0 __Dmain
1 0 0 0 _D4test1fFZC4test1A1gMFZi
---
How can I tell whether the code calls heap allocation functions?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5233] [patch] std.range.put accepts *any* element type when putting to an array.
http://d.puremagic.com/issues/show_bug.cgi?id=5233
--- Comment #2 from Rob Jacques sandf...@jhu.edu 2010-11-18 13:23:19 PST ---
*sigh* Patch version 3. Added support for putting an input range into an output
range.
Unit test:
assert( isOutputRange(Appender!(ubyte[]),string) );
Patch:
void put(R, E)(ref R r, E e) { // BUG, adding template constraints result in a
recursive expansion with isOutputRange
static if ( __traits(compiles, {return R.init.put(E.init);}) ) { // Patch
from Issue 4880
// commit to using the put method
static if (!isArray!R is(typeof(r.put(e {
r.put(e);
} else static if (!isArray!R is(typeof(r.put((e)[0..1] {
r.put((e)[0..1]);
} else {
static assert(false, Cannot put a ~E.stringof~ into a
~R.stringof);
}
} else {
static if (isInputRange!R) {
// Commit to using assignment to front
static if (is(typeof(r.front = e, r.popFront( {
r.front = e;
r.popFront();
} else static if (isInputRange!E is(typeof(put(r, e.front {
for (; !e.empty; e.popFront()) put(r, e.front);
} else static if( isSomeString!R isSomeChar!E ) {
static if( (typeof(r[0])).sizeof E.sizeof ) {
// must do some transcoding around here to support
char[].put(dchar)
Unqual!(typeof(r[0]))[(typeof(r[0])).sizeof == 1 ? 4 : 2]
encoded;
auto len = std.utf.encode(encoded, e);
writeln( typeof(encoded).stringof,\t, typeof(r[0]).sizeof
,\t, E.sizeof );
foreach(c;encoded[0 .. len]) {
r[0] = c;
r.popFront;
}
} else {
r[0] = e;
r.popFront;
}
} else static if(hasSlicing!E is(typeof(e.length == size_t))
is(typeof(put(r, e[0]))) ) {
for (; !e.empty; e = e[1..e.length]) put(r, e[0]);
} else {
static assert(false, Cannot put a ~E.stringof~ into a
~R.stringof);
}
} else {
// Commit to using opCall
static if (is(typeof(r(e {
r(e);
} else static if (is(typeof(r((e)[0..1] {
r((e)[0..1]);
} else static if (isInputRange!E is(typeof(put(r, e.front {
for (; !e.empty; e.popFront()) put(r, e.front);
} else static if(hasSlicing!E is(typeof(e.length == size_t))
is(typeof(put(r, e[0]))) ) {
for (; !e.empty; e = e[1..e.length]) put(r, e[0]);
} else {
static assert(false, Cannot put a ~E.stringof~ into a
~R.stringof);
}
}
}
}
--
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 #14 from Don clugd...@yahoo.com.au 2010-11-18 13:39:08 PST --- (In reply to comment #12) So, you don't want writeln(bi); or to!string(bi) to work? No, that's not what I meant. I would think that ideally, BigInt would work exactly the same way that integers do. to!string(i) - decimal writeln(i) - decimal writefln(%s, i) - decimal writefln(%d, i) - decimal writefln(%f, i) - hex So, ideally, BigInt would do the same: to!string(bi) - decimal writeln(bi) - decimal writefln(%s, bi) - decimal writefln(%d, bi) - decimal writefln(%f, bi) - hex Yes. The thing I do *not* want is where it works for one case but not any of the others. I find that suggestion completely indefensible. BTW, the void toString() was just a typo by me. I meant string toString(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5236] [patch] std.format.formattedRead/unformatValue does not support the raw reading of integer types
http://d.puremagic.com/issues/show_bug.cgi?id=5236
--- Comment #1 from Rob Jacques sandf...@jhu.edu 2010-11-18 14:05:23 PST ---
Also, the unformatValue routines need to wrap the parse statements in a traits
compiles test, in order to support raw reading from byte streams.
i.e.
static if(__traits(compiles, parse!T(input) )) {
return parse!T(input);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5237] New: writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237
Summary: writefln doesn't respect Complex.toString
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2010-11-18 14:19:09 PST ---
import std.complex;
import std.stdio;
void main()
{
cdouble z2 = 10 + 1.5e-6i;
Complex!(double) z;
z.re = 10;
z.im = 1.5e-6;
writefln(z= %.16f z2 = %.16f, z, z2);
writefln(z = %f z2 = %f, z, z2);
writefln(z = %e z2 = %e, z, z2);
writefln(z = %a z2 = %a, z, z2);
}
z = 10+1.5e-06i z2 = 10.+0.0150i
z = 10+1.5e-06i z2 = 10.00+0.01i
z = 10+1.5e-06i z2 = 1.00e+01+1.50e-06i
z = 10+1.5e-06i z2 = 0x1.4p+3+0x1.92a737110e454p-20i
Clearly the format string is not being passed, or is being ignored.
--
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 #15 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-18 14:32:17 PST --- Well, then I think that we agree on the desired eventual functionality. But I do think that in the interim, it would be a good idea to add string toString() to BigInt with the idea that it would be removed as soon as the fancier toString() stuff is sorted out. That way, at least _some_ of the desired behavior would work rather than forcing you to call the current toString() with a delegate just to get a string representation for a BigInt. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3031] scoped static var conflicts while linking
http://d.puremagic.com/issues/show_bug.cgi?id=3031 Lukasz Wrzosek luk.wrzo...@gmail.com changed: What|Removed |Added Attachment #817 is|0 |1 obsolete|| --- Comment #3 from Lukasz Wrzosek luk.wrzo...@gmail.com 2010-11-18 15:08:29 PST --- Created an attachment (id=819) Once again fix added and marked (patch) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5238] New: PATCH: fix return of uninitialised var in interpret.c
http://d.puremagic.com/issues/show_bug.cgi?id=5238 Summary: PATCH: fix return of uninitialised var in interpret.c Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: s.d.hamm...@googlemail.com --- Comment #0 from simon s.d.hamm...@googlemail.com 2010-11-18 16:17:58 PST --- Created an attachment (id=820) PATCH: fix return of uninitialised var in interpret.c As summary: triggered by test/runnable/interpret.d, line 2034 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5148] Incorrect C++ mangling of multiple const char* parameters
http://d.puremagic.com/issues/show_bug.cgi?id=5148 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2010-11-18 20:07:33 PST --- http://www.dsource.org/projects/dmd/changeset/762 -- 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 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Attachment #820|application/octet-stream|text/plain mime type|| Attachment #820 is|0 |1 patch|| -- 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
Brad Roberts bra...@puremagic.com changed:
What|Removed |Added
CC||bra...@puremagic.com
--- Comment #1 from Brad Roberts bra...@puremagic.com 2010-11-18 21:15:05 PST
---
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?
--
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 #2 from Brad Roberts bra...@puremagic.com 2010-11-18 21:24:56 PST --- changing 2109 below to just w[2] rather than w[$-2] (same array index) makes that problem go away. And with that change, the entire test passes, which is great. Just leaves one bug to find. :) Oh, and the error is: runnable/interpret.d(2110): Error: variable w used before set -- 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 #3 from Brad Roberts bra...@puremagic.com 2010-11-18 22:15:48 PST
---
Created an attachment (id=821)
changes to runnable/interpret.d
The problem is with the optimizer, not ctfe. Switching to this form, so that
there's no code for the optimizer to chew on and complain about works:
static assert(is(typeof(Compileable!(
(){
S[4] w = void; // uninitialized array of structs
w[$-2].x = 217; // initialize one member
return w[2].x;
}()).OK
)));
I'll file a separate bug report for that.
Adding a patch for runnable/interpret.d to be applied in addition to simon's
changes.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5239] New: optimizer misreports an used before set error
http://d.puremagic.com/issues/show_bug.cgi?id=5239
Summary: optimizer misreports an used before set error
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bra...@puremagic.com
--- Comment #0 from Brad Roberts bra...@puremagic.com 2010-11-18 22:34:20 PST
---
(an excerpt from runnable/interpret.d)
struct S { int x; }
template Compileable(int z) { bool OK=true;}
int goodfoo3()
{
S[4] w = void; // uninitialized array of structs
w[$-2].x = 217; // initialize one member
return w[2].x; // line 8
}
$ dmd -c -O f.d
f.d(8): Error: variable w used before set
note: filed as d2, but might well exist on d1 as well.. untested
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
