[Issue 4572] std.file.read return type
http://d.puremagic.com/issues/show_bug.cgi?id=4572 David Simcha dsim...@yahoo.com changed: What|Removed |Added CC||dsim...@yahoo.com --- Comment #1 from David Simcha dsim...@yahoo.com 2010-08-03 05:59:07 PDT --- I agree, and here's another reason to add to the list: void[] implies an array that may contain pointers. I just looked at the impl. of std.file and was surprised to learn that it allocates the array as not containing pointers via GC.malloc. However, when you do a new void[N], you get an array that may contain pointers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4572] std.file.read return type
http://d.puremagic.com/issues/show_bug.cgi?id=4572 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #2 from nfx...@gmail.com 2010-08-03 07:15:34 PDT --- I say using the void[] type is a design error in this case. void[] is just a safer void*. void[] should only be used in cases when you have to reference a specific region of memory. You use it because the type system is not expressive enough to describe the actual type (see Variant and so on). But in this case, it's very clear what the actual data type is: it's an array of bytes. File contents are nothing else than untyped bag of bytes. Thus the return type should be ubyte[]. Note that reinterpret casting ubyte[] slices to other arrays or structs is not clean: there are issues of byte order and padding. This too doesn't apply to void[]. There's a clear difference. Tange makes the same error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4574] New: std.regex : breaks with empy string regex
http://d.puremagic.com/issues/show_bug.cgi?id=4574
Summary: std.regex : breaks with empy string regex
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bdom.pub+deeb...@gmail.com
--- Comment #0 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-08-03
08:13:17 PDT ---
import std.regex;
void main() {
foreach(m; match(abcabcabab, regex())) {
writefln(%s[%s]%s, m.pre, m.hit, m.post);
}
}
throws:
core.exception.rangeer...@std.regex(1848): Range violation
The empty string is a perfectly valid regex. (which, IIRC, should match an
input string named src (src.length+1) times)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4572] std.file.read return type
http://d.puremagic.com/issues/show_bug.cgi?id=4572 --- Comment #3 from bearophile_h...@eml.cc 2010-08-03 09:09:48 PDT --- Thank you David and nfxjfg :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4572] std.file.read return type
http://d.puremagic.com/issues/show_bug.cgi?id=4572 --- Comment #4 from nfx...@gmail.com 2010-08-03 09:22:36 PDT --- One can add that .dup-ing a void[] will make all the precaution in std.file.read of allocating the void[] with GC.BlkAttr.NO_SCAN useless. The dup'ed array won't have the NO_SCAN flag set. It really shows that void[] is not the natural type to use here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4576] accepts-invalid: 0/1 argument calls to overloaded function is allowed in presence of variadic function
http://d.puremagic.com/issues/show_bug.cgi?id=4576 --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-08-03 12:29:27 PDT --- Sorry for the mixed comments between TDPL and the ones I've added. The average(); call should issue a compiler error. And a 1-argument call average(0) should issue an error as well. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4576] 0/1 argument calls to overloaded function is allowed in presence of variadic function
http://d.puremagic.com/issues/show_bug.cgi?id=4576 nfx...@gmail.com changed: What|Removed |Added Keywords||accepts-invalid CC||nfx...@gmail.com Summary|accepts-invalid: 0/1|0/1 argument calls to |argument calls to |overloaded function is |overloaded function is |allowed in presence of |allowed in presence of |variadic function |variadic function | --- Comment #2 from nfx...@gmail.com 2010-08-03 12:42:42 PDT --- Keywords go into keyword field. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4576] 0/1 argument calls to overloaded function is allowed in presence of variadic function
http://d.puremagic.com/issues/show_bug.cgi?id=4576 --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-08-03 12:54:15 PDT --- (In reply to comment #2) Keywords go into keyword field. Ah, thanks! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3550] array.dup violates const/invariant without a cast.
http://d.puremagic.com/issues/show_bug.cgi?id=3550 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added Blocks||2573 --- Comment #2 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-08-03 13:25:17 PDT --- Just thought, there must be this bug... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4577] New: Third way to create a std.typecons.Tuple
http://d.puremagic.com/issues/show_bug.cgi?id=4577
Summary: Third way to create a std.typecons.Tuple
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-08-03 15:02:23 PDT ---
Three ways to do something are a lot, but for me it's handy to build a
std.typecons.tuple with just field names, and using the type inference to omit
their types. With good library helper templates the implementation is simple:
import std.typecons: Tuple;
import std.string: split;
import std.metastrings: Format, toStringNow;
template SeriesGen1(string txt, string separator, int max, int min=0) {
static if (min max)
const SeriesGen1 = ;
else static if (min == max)
const SeriesGen1 = Format!(txt, toStringNow!(max));
else
const SeriesGen1 = SeriesGen1!(txt, separator, max-1, min) ~ separator
~
Format!(txt, toStringNow!(max));
}
template SeriesGen2(string txt, string separator, int max, int min=0) {
static if (min max)
const SeriesGen2 = ;
else static if (min == max)
const SeriesGen2 = Format!(txt, toStringNow!(max),
toStringNow!(max));
else
const SeriesGen2 = SeriesGen2!(txt, separator, max-1, min) ~ separator
~
Format!(txt, toStringNow!(max),
toStringNow!(max));
}
// not sure about the ref return value
// can this be named just Tuple?
ref auto Tuple_(string names, T...)(T args)
if (T.length split(names).length == T.length) {
enum string[] fieldNames = split(names);
mixin(return Tuple!( ~
SeriesGen2!(T[%s], fieldNames[%s], , , T.length-1) ~
)( ~
SeriesGen1!(args[%s], , , T.length-1) ~
);
);
}
// demo
import std.stdio: writeln;
ref auto sqr2(int a, float b) {
return Tuple_!q{x y}(a * a, b * b);
}
void main() {
///*
with(sqr2(10, 5.5F)) {
writeln(x, , y);
} // test.d(...): Error: sqr2(10,5.5F) is not an lvalue
//*/
auto xy = sqr2(10, 5.5F);
with(xy) {
writeln(x, , y);
}
with(Tuple!(int, a, float, b)(10, 5.5F)) {
writeln(a, , b);
}
}
I'd like this to overload the std.typecons.Tuple, I hope this is possible.
I am not sure if this enhancement request deserves a 'patch' keyword tag.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4578] New: Regression: ICE: Internal error: ../ztc/cg87.c 1364: var+arr[]
http://d.puremagic.com/issues/show_bug.cgi?id=4578
Summary: Regression: ICE: Internal error: ../ztc/cg87.c 1364:
var+arr[]
Product: D
Version: D1
Platform: Other
OS/Version: Linux
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: baseball@gmail.com
--- Comment #0 from Michael P baseball@gmail.com 2010-08-03 15:52:45 PDT
---
Code to create ICE:
void main()
{
int[] foo;
int y = 2;
int[] c = y + foo[];
}
$ dmd test.d
Internal error: ../ztc/cgcod.c 1596
The same error occurs if using the operators +, -, or %.
The proper error is given with operators * and /. (Proper error I think is what
is being given in 1.061)
In 1.061, I would receive this error:
test.d(5): Error: Array operation y + foo[] not implemented
This seems to be because functions AddExp::toElem, MinExp::toElem and
ModExp::toElem in e2ir.c do not have the code that checks for a non-valid
array. The code from these was taken out in 1.062.
The code seemed to be added for MulExp and DivExp because of this issue:
http://d.puremagic.com/issues/show_bug.cgi?id=3522
but was later taken out of AddExp and MinExp.
Perhaps this code in BinExp::toElem:
if ((tb1-ty == Tarray || tb1-ty == Tsarray)
(tb2-ty == Tarray || tb2-ty == Tsarray)
op != OPeq
)
Should be:
if ((tb1-ty == Tarray || tb1-ty == Tsarray) ||
(tb2-ty == Tarray || tb2-ty == Tsarray)
op != OPeq
)
That might catch array ops errors for all of the xxxExp types.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4579] New: std.typecons.Tuple syntax unpacking sugar
http://d.puremagic.com/issues/show_bug.cgi?id=4579
Summary: std.typecons.Tuple syntax unpacking sugar
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-08-03 17:13:16 PDT ---
In this enhancement request I propose to add syntax sugar to D2 that allows to
unpack std.typecons.Tuple at the calling point.
This enhancement request doesn't ask for a third new kind of tuple, the normal
std.typecons.Tuple Phobos2 one is enough.
Essentially std.typecons.Tuple can be used to have multiple return values in D,
but some syntax sugar helps.
In Python2.x language, that is able to return tuples too, this automatic tuple
unpacking is _very_ common and very handy (D makes this situation a little
different, because std.typecons.Tuple supports named fields, and fields are
statically typed):
def sqr_cube(x):
return x*x, x*x*x
x2, x3 = sqr_cube(10)
(Python2.x also allows nested tuple unpacking with a bit of pattern matching,
and Python3.x allows variable length unpacking with the * syntax.)
This is a function of std.file (Phobos2 of DMD 2.047):
void getTimes(in char[] name, out d_time ftc, out d_time fta, out d_time ftm);
Introducing tuples more into Phobos its signature becomes:
Tuple!(d_time ftc, d_time fta, d_time ftm) getTimes(const string name);
But then you have to use it for example like this:
void main() {
auto t3 = getTimes(filename);
with(t3) {
writeln(ftc, , fta, , ftm);
}
}
While adding a bit of syntax sugar to D it becomes:
void main() {
// Here I have used fc != ftc
(d_time fc, d_time fa, d_time fm) = getTimes(filename);
}
That syntax sugar means something like:
void main() {
auto __temp1 = getTimes(filename);
d_time fc = __temp1.field[0];
d_time fa = __temp1.field[1];
d_time fm = __temp1.field[2];
}
I think that sugar doesn't clash with C syntax, so this syntax doesn't
introduce bugs when porting code from C to D. This new syntax looks natural
enough to me, and handy in high-level-style D programming.
Nested unpacking too is a possibility:
(int x, (int y, int z)) = foo();
See also bug 4577 for Tuples.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4530] Tidier function types
http://d.puremagic.com/issues/show_bug.cgi?id=4530 --- Comment #5 from bearophile_h...@eml.cc 2010-08-03 18:13:23 PDT --- See also enhancement request 4580 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4580] New: Compiler option to port C code or disallow some duplicated C syntax
http://d.puremagic.com/issues/show_bug.cgi?id=4580 Summary: Compiler option to port C code or disallow some duplicated C syntax Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-08-03 18:12:17 PDT --- D language is designed to act as (share the same semantics as) C when a syntax valid in C is used, so you can avoid bad surprises when you port C code to D. In some situations following this general principle is seen as too much costly, so in few advantageous cases D doesn't follow it. Such cases have caused me bugs when I have translated some C code to D. So I'd like something to avoid similar bugs when I perform similar porting. In other situations D keeps both the D-style syntax and C-style syntax to perform something. This double syntax is surely handy when you convert C code to D, but in normal D programming makes the D language more confusing (because there is more than on obvious way to do something), more complex, and has other disadvantages. In the D.learn newsgroup Heywood Floyd has started a short thread about 2D arrays definition, he finds them confusing, and he currently wants to use the int marr[3][5]; syntax. It's bad to have two different syntaxes to define arrays in a language. On the other hand I have found the C-style syntax useful when I have translated some C code to D (later once the code works correctly I have replaced the C definitions with D ones). To solve this problems I propose a new D compiler option, a possible name is -cstyle, but other shorter names are possible. This switch is designed to help porting of C code to D that warns against: - usage of global floating point variables/arrays that in some C programs are used without initialization, assuming they are set to zero (while D initializes them to NaN). This has caused a slow-to-find bug in one of my programs; - cstyle switches on a compile-time warning against the usage of large fixed-sized arrays, that are passed around by reference in C and recently by value in D2. So if they are large the program can get slower in D. (I think D already guards against some C-style arrays usages that exploit the reference nature of array arguments). The purpose of -cstyle is not to split D into two languages, it is to tell apart two different purposes and allow at the same time a safer porting of C code to D and give a chance to deprecate and later remove some bad C syntax from normal D syntax. One more possible purpose for -cstyle: to allow the C-style array definition syntax. So unless -cstyle is used then: int marr[3][5]; is a syntax error. This allows to keep the purpose of C-style array definitions (for porting from C code) while essentially making it deprecated for normal D programs. Another possible purpose for -cstyle: to allow the C-style function pointer syntax. This allows to disallow such syntax in normal D programs. This syntax is confusing and unreadable and can generate bugs, on this see also bug 4530 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4385] Uncaught exceptions should call abort() at the place where the exception was thrown
http://d.puremagic.com/issues/show_bug.cgi?id=4385 --- Comment #4 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-08-03 20:13:11 PDT --- Why not call abort from onAssertError function? (In reply to comment #2) What I don't get is why this works with object dtors that are run as the stack unwinds though. If I remember it correctly, objects are destructed during the catch phase. I think, this won't work with sjlj exceptions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4443] Optimizer produces wrong code for || or with struct arrays
http://d.puremagic.com/issues/show_bug.cgi?id=4443
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Don clugd...@yahoo.com.au 2010-08-03 21:56:32 PDT ---
This is a really subtle code generation bug. The buggy bit of code is below.
In this section of code, the expression size is one register.
In the bit of code at L13, it checks to see if the addition factor is already
in a register.
In this case, it is, BUT it's actually in a double register: the {ptr, length}
pair is a ulong, and here it's been cast to uint to get the length.
So isregvar() returns BOTH registers in regm.
Then, at the end of this section of code, the register to use is selected with
a call to findreg(). But it just returns the first register which is correct
only if there is only one register.
In this patch, I just use the LSW returned from isregvar. It would also be
possible to change isregvar() to only return the LSW in the case where a cast
to smaller type has occured, but I don't know what other code expects from
isregvar.
Not sure if the tysize() check is necessary. Maybe it could just be retregs = 1
reg1;
PATCH: cod2.c, cdorth(), line 362. (Does 1reg1 work if reg1 is 0?).
L13:
regm_t regm;
if (e11-Eoper == OPvar isregvar(e11,regm,reg1))
{
+if (tysize[tybasic(e11-Ety)]= REGSIZE)
+ retregs = 1 reg1; // Only want the LSW
+else
retregs = regm;
c1 = NULL;
freenode(e11);
}
else
c1 = codelem(e11,retregs,FALSE);
}
rretregs = ALLREGS ~retregs;
c2 = scodelem(ebase,rretregs,retregs,TRUE);
{
regm_t sregs = *pretregs ~rretregs;
if (!sregs)
sregs = ALLREGS ~rretregs;
c3 = allocreg(sregs,reg,ty);
}
+ // BUG: We should ensure there is only register in retregs
reg1 = findreg(retregs);
Also noticed that in cod4.c, cdmsw() line 2838, there's an incorrect comment.
retregs = mMSW;// want LSW only
This should of course be // want MSW only
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3528] FreeBSD patches for druntime.
http://d.puremagic.com/issues/show_bug.cgi?id=3528 Shin Fujishiro rsi...@gmail.com changed: What|Removed |Added Attachment #634 is|0 |1 obsolete|| --- Comment #10 from Shin Fujishiro rsi...@gmail.com 2010-08-03 22:15:29 PDT --- Created an attachment (id=702) Patch against svn r352 Updated the patch for svn trunk r352. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3528] FreeBSD patches for druntime.
http://d.puremagic.com/issues/show_bug.cgi?id=3528 Shin Fujishiro rsi...@gmail.com changed: What|Removed |Added Attachment #702 is|0 |1 obsolete|| --- Comment #11 from Shin Fujishiro rsi...@gmail.com 2010-08-03 22:44:52 PDT --- Created an attachment (id=703) Patch against svn r352 Oops, forgot to eliminate backtrace stuffs that FreeBSD libc does'nt have. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
