[Issue 5756] amap() and maybe afilter() too
http://d.puremagic.com/issues/show_bug.cgi?id=5756 --- Comment #1 from bearophile_h...@eml.cc 2011-03-23 23:47:04 PDT --- As in std.parallelism, I suggest to add a second optional argument to the amap()/afilter(), an optional buffer to return the result. If the buffer is provided, it must be the same length as the range. So you write: auto numbers = iota(10); auto squareRoots = new double[numbers.length]; amap!sqrt(numbers, squareRoots); Instead of: auto numbers = iota(10); auto squareRoots = new double[numbers.length]; copy(map!sqrt(numbers), squareRoots); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5761] std.datetime: Date.this(int day) conversion fails for Dec 30 of leap years
http://d.puremagic.com/issues/show_bug.cgi?id=5761 --- Comment #1 from Jonathan M Davis 2011-03-23 23:32:08 PDT --- Now, _that_ was a nasty little math bug. Well, I now have a fix, and if you need it, the code can be gotten here: https://github.com/jmdavis/phobos/tree/datetime I'm revamping std.datetime's unit tests at the moment, and I probably won't create a pull request until that's done. Also, with these changes, the unit tests currently fail on Windows due to bug# 5781, so that's going to need to be fixed before a pull request is made. However, the changes are posted in the datetime branch of my github repository if you need them before they actually get merged into Phobos proper. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5781] New: std.datetime: On Windows, times off by one hour in some years due to DST rule changes
http://d.puremagic.com/issues/show_bug.cgi?id=5781
Summary: std.datetime: On Windows, times off by one hour in
some years due to DST rule changes
Product: D
Version: unspecified
Platform: All
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis 2011-03-23 23:26:10
PDT ---
If are on Windows 7 in one of most of the time zones in America, this lovely
little program
import std.datetime;
import std.stdio;
void main()
{
writeln(SysTime(Date(1999, 3, 1)));
writeln(SysTime(Date(1999, 3, 8)));
writeln(SysTime(Date(1999, 3, 14)));
writeln(SysTime(DateTime(1999, 3, 14, 1, 0, 0)));
writeln(SysTime(DateTime(1999, 3, 14, 2, 0, 0)));
writeln(SysTime(DateTime(1999, 3, 14, 3, 0, 0)));
writeln(SysTime(Date(1999, 3, 15)));
writeln(SysTime(Date(1999, 3, 22)));
writeln(SysTime(Date(1999, 3, 29)));
writeln(SysTime(Date(1999, 4, 1)));
writeln(SysTime(Date(1999, 4, 3)));
writeln(SysTime(DateTime(1999, 4, 4, 1, 0, 0)));
writeln(SysTime(DateTime(1999, 4, 4, 2, 0, 0)));
writeln(SysTime(DateTime(1999, 4, 4, 3, 0, 0)));
writeln(SysTime(Date(1999, 4, 5)));
}
results in this output:
1999-Mar-01 00:00:00
1999-Mar-08 00:00:00
1999-Mar-14 00:00:00
1999-Mar-14 01:00:00
1999-Mar-14 01:00:00
1999-Mar-14 02:00:00
1999-Mar-14 23:00:00
1999-Mar-21 23:00:00
1999-Mar-28 23:00:00
1999-Mar-31 23:00:00
1999-Apr-02 23:00:00
1999-Apr-04 00:00:00
1999-Apr-04 01:00:00
1999-Apr-04 03:00:00
1999-Apr-05 00:00:00
The DST rules changed in most of North America in 2007. This bug occurs in any
year prior to 2007 for time zones in North America which had their DST rules
changed in 2007. It likely similarly affects other time zones whose DST rules
changed at some point. I don't know if this affects versions of Windows prior
to 7. I would be surprised if it didn't affect Vista, but I suspect that it
doesn't affect XP (it might though). DYNAMIC_TIME_ZONE_INFORMATION was added
with Windows Vista, and I suspect that that is what is being used under the
hood in 7. And if that is the case, then XP likely has different behavior. And
I can't use DYNAMIC_TIME_ZONE_INFORMATION in Phobos, since we can't assume that
Windows programmers are using Vista or newer and do not want to compile for XP.
Essentially, it has to do with the fact that in Windows 7, the Windows'
function SystemTimeToTzSpecificLocalTime doesn't really use the
TIME_ZONE_INFORMATION struct that it's given. Instead, it looks up the correct
time zone rules for the year in question. Wine does _not_ have this behavior,
and I did most of my Windows testing for std.datetime testing in Wine (I'm now
using VirtualBox with a Windows 7 install in it, which is a much better
solution overall, so that shouldn't be a problem in the future).
I'm not quite sure what the best fix for this is, but I'll sort it out and fix
it fairly soon. In the meantime, here's a bug report so that it's clear that
the bug exists, and it'll be clear when it's fixed. And if you have a Windows
XP or Vista box and are in the Pacific, Mountain, or Eastern time zones, I'd
appreciate it if you could run the above code and add the results to this bug
so that I know if XP and/or Vista have the same behavior.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5780] New: handles[patch] std.traits.hasIndirections incorrectly handels static arrays
http://d.puremagic.com/issues/show_bug.cgi?id=5780
Summary: handles[patch] std.traits.hasIndirections incorrectly
handels static arrays
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch
Severity: critical
Priority: P1
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: sandf...@jhu.edu
--- Comment #0 from Rob Jacques 2011-03-23 22:05:38 PDT ---
Problem:
std.traits.hasIndirections currently does not return true for static arrays of
types with indirections. More fundamentally, it's unit tests do not verify it's
output for all template instances. I've set the priority of this bug based on
the fact that manual memory allocation routines are apt to utilize
hasIndirections to determine whether or not to apply the no scan GC attribute
and getting this wrong results in memory stomping/corruption.
Solution:
I've added detection and handling of static arrays to hasIndirectionsImpl.
Also, to prevent future unforeseen corner cases, I've added a private template,
hasIndirectionsUnittest, which allows each instance of hasIndirections!T to
generate a unit test which verifies the value of hasIndirections!T against T's
runtime GC flags. Also, a specific unit test for static arrays was added.
Patch: (Based on DMD 2.052)
/**
Returns $(D true) if and only if $(D T)'s representation includes at
least one of the following: $(OL $(LI a raw pointer $(D U*);) $(LI an
array $(D U[]);) $(LI a reference to a class type $(D C).)
$(LI an associative array.) $(LI a delegate.))
*/
template hasIndirections(T)
{
enum hasIndirections = hasIndirectionsUnittest!T.implementation;
}
// Tests hasIndirections against the GC's runtime info for every T
private template hasIndirectionsUnittest(T)
{
enum implementation = hasIndirectionsImpl!(RepresentationTypeTuple!T);
unittest {
assert( hasIndirections!T == (typeid(T[]).next.flags & 1) );
}
}
template hasIndirectionsImpl(T...)
{
static if (!T.length)
{
enum hasIndirectionsImpl = false;
}
else static if(isFunctionPointer!(T[0]))
{
enum hasIndirectionsImpl = hasIndirectionsImpl!(T[1 .. $]);
}
else static if(isStaticArray!(T[0]))
{
enum hasIndirectionsImpl = hasIndirectionsImpl!(T[1 .. $]) ||
hasIndirectionsImpl!(RepresentationTypeTuple!(typeof(T[0].init[0])));
}
else
{
enum hasIndirectionsImpl = isPointer!(T[0]) || isDynamicArray!(T[0]) ||
is (T[0] : const(Object)) || isAssociativeArray!(T[0]) ||
isDelegate!(T[0]) || is(T[0] == interface)
|| hasIndirectionsImpl!(T[1 .. $]);
}
}
unittest
{
struct S1 { int a; Object b; }
static assert(hasIndirections!(S1));
struct S2 { string a; }
static assert(hasIndirections!(S2));
struct S3 { int a; immutable Object b; }
static assert(hasIndirections!(S3));
static assert(hasIndirections!(int[string]));
static assert(hasIndirections!(void delegate()));
interface I;
static assert(hasIndirections!I);
static assert(!hasIndirections!(void function()));
static assert(hasIndirections!(void*[1]));
static assert(!hasIndirections!(byte[1]));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5779] Bad value range propagation for ternary operator
http://d.puremagic.com/issues/show_bug.cgi?id=5779 Vladimir changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Vladimir 2011-03-23 21:32:48 PDT --- Oops :) You're probably right. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5779] Bad value range propagation for ternary operator
http://d.puremagic.com/issues/show_bug.cgi?id=5779
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #1 from Don 2011-03-23 21:31:51 PDT ---
(In reply to comment #0)
> void main()
> {
> bool b = true;
> ubyte bit = b ? 1 : 0;
> }
>
> With warnings enabled, the compiler complains:
>
> test.d(4): Warning: implicit conversion of expression (b ? 1 : 0) of type int
> to ubyte can cause loss of data
>
> Doesn't happen with D2 (2.052).
D1 doesn't have range propagation! It's a D2 feature, which eliminates these
kind of nonsense errors. I think this bug is probably invalid.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5779] New: Bad value range propagation for ternary operator
http://d.puremagic.com/issues/show_bug.cgi?id=5779
Summary: Bad value range propagation for ternary operator
Product: D
Version: D1
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thecybersha...@gmail.com
--- Comment #0 from Vladimir 2011-03-23 21:24:03 PDT
---
void main()
{
bool b = true;
ubyte bit = b ? 1 : 0;
}
With warnings enabled, the compiler complains:
test.d(4): Warning: implicit conversion of expression (b ? 1 : 0) of type int
to ubyte can cause loss of data
Doesn't happen with D2 (2.052).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5778] New: Missing attributes.
http://d.puremagic.com/issues/show_bug.cgi?id=5778 Summary: Missing attributes. Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: blood.of.l...@gmail.com --- Comment #0 from Bernard Helyer 2011-03-23 19:19:56 PDT --- Various attributes are not described or even listed on http://www.digitalmars.com/d/2.0/attribute.html . >From the top of my head: @safe @trusted @system pure nothrow -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5777] New: Move semantics require full spec NRVO
http://d.puremagic.com/issues/show_bug.cgi?id=5777
Summary: Move semantics require full spec NRVO
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2011-03-23 18:40:27 PDT ---
DMD supports Named Return Value Optimization(NRVO), but now this
doesn't work for struct that has @disabled postblit and user-defined
destructor (e.g. std.typecons.scoped).
This looks trivial, but serious problem.
1. Need of incorporating NRVO into the language specifications
D does not contain rvalue seantinc in its type system.
('ref' is storage class, not part of type. This means casting
is useless for this purpose, unlike C++.)
Except for only one, This means D has no way that convert from lvalue
to rvalue in current language spec.
The one way is NRVO. This is not only trivial optimization, but also
core of move semantics in D.
T f(){
T ret;// &ret == hidden pointer, and *hidden is 'move target'.
// In this example, share memory of t.
ret = ...
return ret;// NRVO.
}
T t = f();// t's memory address is taken hidden pointer
Moving object caller to callee is now D supports, but reversed flow is
limitation. To full support moving callee to caller through return value,
NRVO is required.
2. std.algorithm.move problem
If Issue 4499 will be fixed, unary std.algorithm.move() will not work
on noncopyable/has expplicit destructor object.
To give correct behavior, NRVO spec update is need.
3. ABI problem
In http://digitalmars.com/d/2.0/abi.html 'Return Value' term,
struct its size is less than 8 byte is returned using registers.
Issue 4500 is scoped!T and self-referenced class problem, but the way
resolving it will need true NRVO. That has following spec: Any size object
returned through hidden pointer,
if the object has elaborate destructor at least.
See http://d.puremagic.com/issues/show_bug.cgi?id=4500#c5 . Attachment code
includes workaround for this issue, But it's too ugly.
Do you think?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4500] scoped moves class after calling the constructor
http://d.puremagic.com/issues/show_bug.cgi?id=4500 Kenji Hara changed: What|Removed |Added CC||k.hara...@gmail.com --- Comment #6 from Kenji Hara 2011-03-23 18:11:08 PDT --- (In reply to comment #5) > Created an attachment (id=933) [details] > Fixed scoped > > I tried to fix this issue. > It succeeded, but resulting code includes ugly hack. I worked on 64bit Windows 7. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4500] scoped moves class after calling the constructor
http://d.puremagic.com/issues/show_bug.cgi?id=4500 --- Comment #5 from Kenji Hara 2011-03-23 18:02:28 PDT --- Created an attachment (id=933) Fixed scoped I tried to fix this issue. It succeeded, but resulting code includes ugly hack. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5765] ^^ and << with BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=5765 --- Comment #8 from bearophile_h...@eml.cc 2011-03-23 16:40:37 PDT --- (In reply to comment #7) > They are not system languages. The comparison is irrelevant. Well, Lisp was used plenty as a system language. D wants to be a multi-purpose language, and it already has a multi-precision library, and I see no harm in using this library for purposes not anticipated by the BigInt author. > A type that you can be used as a drop-in replacement for integers but will > warn > of overflow, is 100 times simpler than BigInt. Why don't you just write it? Often I don't just want to watch for overflows, I'd also like the program to give a correct answer if for mistake one intermediate computation needs 70 bits long integers (and I don't know it). In the Project Euler (http://projecteuler.net/ ) there are usually ways to avoid multi-precision numbers, but if you are not careful it's not hard to have larger intermediate values. In this case 64 bit values give wrong results, while the small programs in Python give the correct result. ShedSkin is a Python-->C++ compiler, recently it has added support for 64 bit integers too, this has allowed it to compile 131 out of 204 Python Euler solutions: http://shed-skin.blogspot.com/2010/05/shedskin-versus-psyco-for-131-project.html Most of the solutions that can't be compiled with ShedSkin require multi-precision numbers. Often the final result is a 32 bit number, but intermediate values are larger than 64 bit, and ShedSkin gives a wrong result on them. This is an example why multi-precision computations are useful, to produce correct results. The point here is that overflow errors are not enough. Thank you for your answers Don, and sorry for my insistent nature :-) Feel free to close this bug report when you see it fit. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5773] sort() and topN() fail on sliced/resized array of tuples
http://d.puremagic.com/issues/show_bug.cgi?id=5773 --- Comment #4 from kenn...@gmail.com 2011-03-23 16:13:23 PDT --- The overlapping array copy exception should be the same as issue 5705. Not sure about the segfault, as I can't reproduce a segfault (only the same overlapping array copy exception is thrown). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5773] sort() and topN() fail on sliced/resized array of tuples
http://d.puremagic.com/issues/show_bug.cgi?id=5773
kenn...@gmail.com changed:
What|Removed |Added
CC||kenn...@gmail.com
--- Comment #3 from kenn...@gmail.com 2011-03-23 16:00:52 PDT ---
(In reply to comment #1)
> Perhaps this is just me being stupid -- trying to sort things that can't be
> compared? However, if I use a custom struct (instead of a tuple) I get an
> explicit compiler error about that (which is kind of useful ;-)
Except that Tuples *can* can compared. Example:
--
import std.typecons;
alias Tuple!(real,uint) Entry;
void main(){
assert(Entry(1.0, 4) > Entry(0.5, 9));
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5775] "body" keyword is unnecessary
http://d.puremagic.com/issues/show_bug.cgi?id=5775 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis 2011-03-23 15:55:57 PDT --- cent and ucent _should_ be kept around. They're _supposed_ to be unused keywords at this point. The idea is that if/when we need to add 128 bit integers to the language, we already have keywords for them. That way, we'll be able to add them without breaking code. macro should likely be kept in case we actually do something with AST macros (or some other macro-like mechanism) in a future version of the language. We may or may not care about keeping typedef once the construct that it's currently used has been removed. We could probably remove it. The same goes for delete. body... Well, I tend to agree that one is totally unnecessary. It probably simplifies the parsing a bit, but unless it's needed to keep the grammar context-free (which it might be, depending on what the exact grammar is for in, out, and body blocks - though I doubt it), it should be able to be removed. However, since it's in the language and its use hasn't changed at all over time (as far as I know), Waler at least thought that we should have it, and unless something about the situation or his opinion has changed in the interim, I doubt that he'll want to get rid of it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5775] "body" keyword is unnecessary
http://d.puremagic.com/issues/show_bug.cgi?id=5775 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2011-03-23 15:43:22 PDT --- Considering the strong resistance against adding new kewords to D, in D there are several unused keywords, like "typedef", "macro", "body", "delete", "cent", "ucent"... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5776] New: DMD assert. failure on topN with custom comparison/data in inner function
http://d.puremagic.com/issues/show_bug.cgi?id=5776
Summary: DMD assert. failure on topN with custom
comparison/data in inner function
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: mag...@hetland.org
--- Comment #0 from Magnus Lie Hetland 2011-03-23 15:29:33
PDT ---
Running DMD 2.052 on OS X. When I try to compile the following program (two
files), by executing foo.d, I get the error
Assertion failed: (!vthis->csym), function toObjFile, file glue.c, line 703.
If I try to compile without myLess, I get:
Error: function std.algorithm.topN!("a < b",cast(SwapStrategy)0,uint[]).topN
compiler error, parameter 'r', bugzilla 2962?"
// foo.d:
#!/usr/bin/env rdmd -inline
import std.random;
import bar;
void main() {
func();
}
// bar.d:
import std.algorithm;
void func() {
bool myLess(uint a, uint b) {
return a < b;
}
void inner(uint[] slice) {
topN!myLess(slice, 0);
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5773] sort() and topN() fail on sliced/resized array of tuples
http://d.puremagic.com/issues/show_bug.cgi?id=5773 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com --- Comment #2 from Andrei Alexandrescu 2011-03-23 15:19:12 PDT --- Thanks for the findings. They definitely point to bugs in sort and topN. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5775] New: "body" keyword is unnecessary
http://d.puremagic.com/issues/show_bug.cgi?id=5775
Summary: "body" keyword is unnecessary
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: alvaro.seg...@gmail.com
--- Comment #0 from Alvaro 2011-03-23 14:46:55 PDT ---
D already has a long list of keywords, and those reserved words can't be used
as identifiers. "body" in particular is a common noun that programmers would
gladly use as variable name in physics simulation, astronomy, mechanics, games,
health, etc. I think "body" can be removed from D with no harm, and with the
benefit of allowing the name as identifier.
Rationale: Functions in C and derived languages have always had a body and they
never needed a keyword. In D, "body" is used to mark the actual body of a
function after the optional "in" and/or "out" contract blocks. From the
documentation:
in{
...contract preconditions...
}
out (result){
...contract postconditions...
}
body{
...code...
}
But the body keyword can be omitted and still interpret the code correctly
given the rule: "An unnamed {} block right after an in{} or out{} block when
defining a function, MUST be the function's body".
Thus, the above code would become:
in{
...contract preconditions...
}
out (result){
...contract postconditions...
}
{
...code...
}
and be perfectly understandable, with the benefit of one less keyword.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5774] New: [64 bit] "relocation truncated to fit" with __gshared array, while(), and $
http://d.puremagic.com/issues/show_bug.cgi?id=5774
Summary: [64 bit] "relocation truncated to fit" with __gshared
array, while(), and $
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2011-03-23 14:40:09 PDT ---
Cut down from a failure in core.cpuid. With all of the build problems with
druntime at the moment I'm not able to get any normal file to build on 64bits;
but this is the relevant case from the runtime build. This probably needs -O
-release, since it goes away if I replace 'while' with 'if'; but I haven't
checked which flags are actually necessary.
=
__gshared char[48] dish;
void foo()
{
int end = 0;
while (dish[$-end-1]==0) { ++end; }
}
===
src/core/cpuid.d:(.text._D4core5cpuid3fooFZv+0x9): relocation truncated to fit:
R_X86_64_PC32 against symbol `_D4core5cpuid4dishG48a' defined in .data section
in obj/core/cpuid.o
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5765] ^^ and << with BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=5765 --- Comment #7 from Don 2011-03-23 13:35:05 PDT --- (In reply to comment #6) > (In reply to comment #5) > > > That's a false consistency. T ^^ int is the common operation, not T ^^ T. > > Really. BigInt ^^ BigInt isn't a BigInt. It's too big to be representable. > > Python3 (and Lisp-family languages, and others) use multi-precision integers > on > default, but most people don't store large numbers in them, most times they > store little numbers, and most people doesn't use them for cryptography. They are not system languages. The comparison is irrelevant. > I am not going to use D BigInts for cryptography. 99.9% times inside BigInts > I'll keep numbers less than 63 bit long. I'd like to use BigInt as in Python > to > avoid the problems caused by int, because currently in D there are no integer > overflow tests, because Walter doesn't want them. OK, now the truth comes out. You shouldn't be using BigInt for that. That's a very simple task. > The first and by a wide margin most important purpose of multi-precision > integers is not to represent huge numbers or to do cryptography, but to free > the mind of the programmer from being forced to think all the time about > possible overflows breaking the code he/she is writing, freeing that part of > attention, and allowing him/her to focus more on the algorithm instead. Sorry, the viewpoint that BigInt is a workaround for your personal hobby horse (integer overflow) has ABSOLUTELY ZERO support from me. BigInt is for arithemetic on big integers. It is not for "freeing the programmers mind" of overflow. A type that you can be used as a drop-in replacement for integers but will warn of overflow, is 100 times simpler than BigInt. Why don't you just write it? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5773] sort() and topN() fail on sliced/resized array of tuples
http://d.puremagic.com/issues/show_bug.cgi?id=5773 --- Comment #1 from Magnus Lie Hetland 2011-03-23 13:17:29 PDT --- Perhaps this is just me being stupid -- trying to sort things that can't be compared? However, if I use a custom struct (instead of a tuple) I get an explicit compiler error about that (which is kind of useful ;-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5773] New: sort() and topN() fail on sliced/resized array of tuples
http://d.puremagic.com/issues/show_bug.cgi?id=5773
Summary: sort() and topN() fail on sliced/resized array of
tuples
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: mag...@hetland.org
--- Comment #0 from Magnus Lie Hetland 2011-03-23 12:52:03
PDT ---
Sample program:
import std.algorithm, std.typecons;
void main() {
alias Tuple!(real,uint) entry;
auto entries = new entry[100];
foreach (i, ref e; entries) {
e[0] = 3.14*i;
e[1] = i;
}
entries = entries[1 .. $];
// sort(entries);
// topN(entries, 50);
}
When uncommented (on their own), the sort statement gives a segmentation fault,
and the topN statement gives the error "object.Exception@src/rt/arraycat.d(40):
overlapping array copy".
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5772] New: Tuple containing typedefed value causes error in format.d
http://d.puremagic.com/issues/show_bug.cgi?id=5772
Summary: Tuple containing typedefed value causes error in
format.d
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: mag...@hetland.org
--- Comment #0 from Magnus Lie Hetland 2011-03-23 12:48:08
PDT ---
Sample program:
import std.typecons;
typedef uint oid_t;
void main() {
// Tuple!(uint,uint) key; // Works
Tuple!(oid_t,oid_t) key; // Doesn't work
}
Error observed when compiling when using DMD 2.052:
/path/to/src/phobos/std/format.d(1579): Error: function
std.format.formatValue!(Appender!(string),oid_t,immutable(char)).formatValue is
deprecated
/path/to/src/phobos/std/format.d(306): Error: template instance
std.format.formatGeneric!(Appender!(string),oid_t,immutable(char)) error
instantiating
/path/to/src/phobos/std/typecons.d(507):instantiated from here:
formattedWrite!(Appender!(string),immutable(char),oid_t)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5765] ^^ and << with BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=5765 --- Comment #6 from bearophile_h...@eml.cc 2011-03-23 10:55:03 PDT --- (In reply to comment #5) > That's a false consistency. T ^^ int is the common operation, not T ^^ T. > Really. BigInt ^^ BigInt isn't a BigInt. It's too big to be representable. Python3 (and Lisp-family languages, and others) use multi-precision integers on default, but most people don't store large numbers in them, most times they store little numbers, and most people doesn't use them for cryptography. I am not going to use D BigInts for cryptography. 99.9% times inside BigInts I'll keep numbers less than 63 bit long. I'd like to use BigInt as in Python to avoid the problems caused by int, because currently in D there are no integer overflow tests, because Walter doesn't want them. The first and by a wide margin most important purpose of multi-precision integers is not to represent huge numbers or to do cryptography, but to free the mind of the programmer from being forced to think all the time about possible overflows breaking the code he/she is writing, freeing that part of attention, and allowing him/her to focus more on the algorithm instead. This is one of the causes that explain why Python is good to write prototypes, allowing to implement algorithms faster than most other languages (D included). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5771] New: Template constructor auto ref and do not work
http://d.puremagic.com/issues/show_bug.cgi?id=5771
Summary: Template constructor auto ref and do not work
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2011-03-23 07:00:57 PDT ---
Test code:
struct S
{
this(A)(auto ref A a){} // line 3
}
void main()
{
S s = S(10);
}
Line 3 causes error 'Error: auto can only be used for template function
parameters'.
Workaround is follows:
struct S
{
template __ctor(A){ // workaround
ref typeof(this) __ctor(auto ref A a){ ...; return this; }
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5765] ^^ and << with BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=5765 --- Comment #5 from Don 2011-03-23 06:57:19 PDT --- (In reply to comment #4) > (In reply to comment #3) > > > The thing I'm really worried about is this: > > BigInt a, b, c; > > > > a = (a ^^ b) % c; > > This is an attempt to do modular exponentiation, which comes up frequently > > in > > cryptography. The code is mathematically correct, but completely wrong in > > practice. > I suggest to add a similar function to std.math or std.bigint. Of course, that's what I was implying. Note that it is a totally different operation to ^^. > Also the D > compiler may recognize the (x^^y)%z pattern and replace it with a power mod > function call. I think that's asking too much. Also note that it doesn't cover the two step pattern where someone does: x = x ^^ y ; x %= z; > > So I would rather give an informative static assert for the BigInt ^^ BigInt > > case. > > Python allows you to use the power/shift with multi-precision numbers too, if > you want. The multi-precision numbers can be used transparently, syntax-wise. > If you have D templated code that you want to use with both BigInt and int you > will have to use a static if to change the code from x^^y to > BigInt(x)^^y.toInt() (or call a little pow template function that does the > same, losing infix operator syntax again), this isn't good. That's a false consistency. T ^^ int is the common operation, not T ^^ T. Really. BigInt ^^ BigInt isn't a BigInt. It's too big to be representable. > BitInt are meant to > work as integers, mostly. I'd like a D program to work with as few changes as > possible if I replace int with BigInts or BigInts with ints (in some > situations > I may write the code with BigInts, see the results and then try to write the > same with ints/longs, to spot the overflows). So? These ones which currently don't compile, will definitely cause problems with ints/longs as well. You're just getting the error message at compile time rather than at run time. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5770] New: Template constructor bypass access check
http://d.puremagic.com/issues/show_bug.cgi?id=5770
Summary: Template constructor bypass access check
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2011-03-23 06:46:34 PDT ---
Test code:
module a
struct S
{
private:
this(int n){}
}
struct T
{
private:
this(A...)(A args){}
}
module b;
import a;
void main()
{
// auto s = S(10); // is not accessible
auto t = T(20); // compile succeeded, NG
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5765] ^^ and << with BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=5765 --- Comment #4 from bearophile_h...@eml.cc 2011-03-23 05:55:03 PDT --- (In reply to comment #3) > The thing I'm really worried about is this: > BigInt a, b, c; > > a = (a ^^ b) % c; > This is an attempt to do modular exponentiation, which comes up frequently in > cryptography. The code is mathematically correct, but completely wrong in > practice. In Python 2.6 the built-in pow function has a third optional argument, that's the modulus, that uses a more efficient algorithm to perform the powermod (note the second 6 that's not a multi-precision value): >>> (20 ** 125) % 7 6L >>> pow(20, 125, 7) 6 I suggest to add a similar function to std.math or std.bigint. Also the D compiler may recognize the (x^^y)%z pattern and replace it with a power mod function call. > So I would rather give an informative static assert for the BigInt ^^ BigInt > case. Python allows you to use the power/shift with multi-precision numbers too, if you want. The multi-precision numbers can be used transparently, syntax-wise. If you have D templated code that you want to use with both BigInt and int you will have to use a static if to change the code from x^^y to BigInt(x)^^y.toInt() (or call a little pow template function that does the same, losing infix operator syntax again), this isn't good. BitInt are meant to work as integers, mostly. I'd like a D program to work with as few changes as possible if I replace int with BigInts or BigInts with ints (in some situations I may write the code with BigInts, see the results and then try to write the same with ints/longs, to spot the overflows). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5769] struct elaborate constructor should make rvalue
http://d.puremagic.com/issues/show_bug.cgi?id=5769
--- Comment #1 from Kenji Hara 2011-03-23 05:47:01 PDT ---
Fixing thi bug is difficult for me.
DMD internally behavior is...
1.Elaborate constructor returns this reference internally.
-> see CtorDeclaration::semantic()
2.Elaborate constructor call T(args) is translated like (T __ctmp,
__ctmp.__ctor(args)) and __ctmp.__ctor returns ref T.
-> see CallExp::semantic
Trivial fix patch is follwing, but this causes copying value.
src/func.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/func.c b/src/func.c
index c3fd455..ea48670 100644
--- a/src/func.c
+++ b/src/func.c
@@ -2953,7 +2953,7 @@ void CtorDeclaration::semantic(Scope *sc)
#if STRUCTTHISREF
if (ad && ad->isStructDeclaration())
-{ ((TypeFunction *)type)->isref = 1;
+{ //((TypeFunction *)type)->isref = 1;
if (!originalType)
// Leave off the "ref"
originalType = new TypeFunction(arguments, tret, varargs, LINKd,
storage_class | sc->stc);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5769] New: struct elaborate constructor should make rvalue
http://d.puremagic.com/issues/show_bug.cgi?id=5769
Summary: struct elaborate constructor should make rvalue
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2011-03-23 05:34:02 PDT ---
Struct literal/constructor call should make rvalue.
Related issue is issue5178.
Test code:
struct S// has default parameterized constructor
{
int n;
}
struct T// has normal constructor
{
this(int n){}
// ref T __ctor(int n){ return this; } // dmd generates internally like this
}
struct T2
{
template __ctor() // workaround
{
T2 __ctor(int n){ return this; } // return copied rvalue
}
}
// lvalue checker
bool checker(T...)(auto ref T t){ return __traits(isRef, t[0]); }
import std.stdio;
void main()
{
int n =20;
S s = S(20);
T t = T(20);
T2 t2 = T2(20);
writefln("%s / %s", checker( 10) , checker( n)); // false/true, ok
writefln("%s / %s", checker( S(10)), checker( s)); // true /true, NG
(Fixed by issue5178 patch)
writefln("%s / %s", checker( T(10)), checker( t)); // true /true, NG!!!
writefln("%s / %s", checker(T2(10)), checker(t2)); // false/true, ok
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5765] ^^ and << with BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=5765
--- Comment #3 from Don 2011-03-23 03:42:32 PDT ---
OK, although I don't think that the case with Ackermann code is so bad. It's
basically giving you a compile-time warning that the function blows up very,
very easily. Having seen this, it becomes obvious that the m=4 case will blow
up for n>2, and therefore that the m=5 will blow up for n>0, and the m>=6 will
blow up for any n. Since this only leaves a total of 4 cases, A(4,0) = 13,
A(4,1) = A(5,0) = 65533, and A(4,2), why not continue the optimization, and
eliminate the recursion entirely? So I think it encourages you to write better
quality code. I think it's quite bizarre to stop at m=3, so I don't find this
example convincing.
The thing I'm really worried about is this:
BigInt a, b, c;
a = (a ^^ b) % c;
This is an attempt to do modular exponentiation, which comes up frequently in
cryptography. The code is mathematically correct, but completely wrong in
practice.
So I would rather give an informative static assert for the BigInt ^^ BigInt
case.
(Definitely, it shouldn't just fail the way it does now).
> How do I perform the equivalent of str(ackermann(4, 2)) with BigInt?
format("%d", ackermann(4,2))
>The bottom of this page shows a duplication to me:
>http://www.digitalmars.com/d/2.0/phobos/std_bigint.html
You're right. A new ddoc bug.
--
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 #37 from Benjamin Thaut 2011-03-23 00:56:13 PDT --- (In reply to comment #36) > What's the status of Windows stack trace integration? > > Note that Benjamin's code needs to be updated by adding an opApply version > with > index to class Callstack. I just updated the code on my blog, the opApply issue is fixed and it is also under a new licence which hopefully removes the problem of adding it to phobos. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
