[Issue 4099] Inconsistent behaviour of ++/-- when mixing opUnary and 'alias this'.
http://d.puremagic.com/issues/show_bug.cgi?id=4099 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 2011-08-25 00:23:10 PDT --- https://github.com/D-Programming-Language/dmd/commit/09998d8759d698ec25f9895734e64734a7f78a30 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5645] std.range.drop(), std.range.slice()
http://d.puremagic.com/issues/show_bug.cgi?id=5645 --- Comment #3 from bearophile_h...@eml.cc 2011-08-25 00:44:25 PDT --- (In reply to comment #2) > The drop function has been added Thank you. > take(drop(range, 5), 3); > > Personally, I'm not all that thrilled with idea of adding a function such as > islice, since it's not efficient the way that slices normally are, islice() is a lazy range implemented essentially as take(drop()), so I don't understand why it's not efficient. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5645] std.range.drop(), std.range.slice()
http://d.puremagic.com/issues/show_bug.cgi?id=5645 --- Comment #4 from bearophile_h...@eml.cc 2011-08-25 00:46:14 PDT --- (In reply to comment #3) Now I understand what you meant: "the way that slices normally are". You are right. It contains drop(), so you generally have to iterate the first items to drop. This is slower than array slicing, that's an O(1) operation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5970] fix BigInt.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5970
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #3 from Don 2011-08-25 01:27:40 PDT ---
(In reply to comment #0)
> This is in reply to comment #3 of bug 5765
>
> > > How do I perform the equivalent of str(ackermann(4, 2)) with BigInt?
> >
> > format("%d", ackermann(4,2))
>
> I think it doesn't work with DMD 2.053beta:
>
>
> import std.bigint, std.string;
> void main() {
> format("%d", BigInt(1));
> }
>
>
> It prints:
> std.format.FormatError: std.format Can't convert std.bigint.BigInt to string:
> "string toString()" not defined
You're right. writefln() works, but format() doesn't:
import std.bigint, std.stdio;
void main() {
writefln("%d %x", BigInt(114), BigInt(114)); // works
}
A bit strange, since writefln() should really be using format().
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5970] fix BigInt.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5970 --- Comment #4 from Kenji Hara 2011-08-25 01:40:12 PDT --- (In reply to comment #3) > A bit strange, since writefln() should really be using format(). It is not true. std.string.format() still uses std.format.doFormat(), not formattedWrite(). I think that is old feature. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5970] fix BigInt.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5970 --- Comment #5 from bearophile_h...@eml.cc 2011-08-25 01:53:06 PDT --- See also bug 6448 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3999] Enum equality to an int
http://d.puremagic.com/issues/show_bug.cgi?id=3999
--- Comment #5 from bearophile_h...@eml.cc 2011-08-25 02:19:30 PDT ---
One example of bug caused by the semantic sloppiness of D enums. This is
reduced code of a small game. The main contains a while that loops until the
game is finished.
The original version of this program was simpler, and instead of using the
GameState enum, it just used 0, 1 and -1 constants in the code.
So the original version of isFinished tests if winner() != -1. Later I have
used the enum GameState, that the winner function now returns. Bug I have
forgotten to update the isFinished() function too. The D language doesn't catch
that simple bug:
struct GameBoard {
// ...
enum GameState { inProgress, draw, humanWins, computerWins }
GameState winner() {
// this function used to return -1, 1, 0 values
// ...
}
bool isFinished() {
return winner() != -1; // not updated function!
//return winner() != GameState.inProgress; // correct code!
}
}
void main() {
// ...
Board game;
while (!game.isFinished()) {
// ...
}
// ...
}
In a bigger program it becomes hard to catch a similar bug (this bug was not
found also because of another waeak typing characteristic of D language: inside
isFinished it allowes you to compare an unsigned size_t value with -1, despite
-1 is statically visibly outside the range of possible unsigned values).
If I write similar code in C++11, it catches that bug:
enum class GameState {
inProgress,
draw,
humanWins,
computerWins
};
GameState winner() {
return GameState::draw;
}
bool isFinished() {
return winner() != -1; // line 11, error
}
int main() {}
G++ 4.6.0 outputs:
test.cpp: In function 'bool isFinished()':
test.cpp:11:25: error: no match for 'operator!=' in 'winner() != -0x1'
In D "final switches" where introduces right to avoid this class of bugs (if
you add an item to an enumeration, and you forget to add a case in a final
switch, the final switch will generate an error. This forces you at
compile-time to consider all cases, as pattern matching does in some functional
languages. Accepting enum conversions to ints causes similar bugs).
Please make named D enums strongly typed. Weak typing is better left to old
versions of the C language.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6554] New: Refused two imports of the same module
http://d.puremagic.com/issues/show_bug.cgi?id=6554
Summary: Refused two imports of the same module
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-08-25 02:43:17 PDT ---
This code:
import std.bigint;
void main() {
import std.bigInt;
}
DMD 2.055head gives this error:
test.d(3): Error: module std.bigint from file ...\src\phobos\std\bigInt.d
conflicts with another module bigint from file ...\src\phobos\std\bigint.d
While this code compiles with no errors:
import std.stdio;
void main() {
import std.stdio;
}
I think those cases can't be both correct.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6555] New: Problem with readf
http://d.puremagic.com/issues/show_bug.cgi?id=6555
Summary: Problem with readf
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-08-25 02:53:20 PDT ---
import std.stdio: readf, writef, writeln;
void main() {
int x = 5;
writef("Give x: ");
readf("%d\n", &x);
writeln("\nx: ", x);
}
If there is no input (because that program is called by another one), readf
leaves x unchanged and doesn't raise an exception. I think this is not good.
-
Another problem: on Windows if you run that program from the console, and you
just hit enter, you are allowed to keep giving lines. Is this by design?
...>test
Give x:
555
123
155
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6555] Problem with readf
http://d.puremagic.com/issues/show_bug.cgi?id=6555 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer 2011-08-25 04:19:55 PDT --- readf returns the number of arguments filled in. I don't think an exception is the correct path -- that is too assuming of readf. I think the second problem you raise is a valid concern. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6308] Destruction of temporaries on exception causes unhandled access violation
http://d.puremagic.com/issues/show_bug.cgi?id=6308 Don changed: What|Removed |Added CC||soy...@gmail.com --- Comment #10 from Don 2011-08-25 08:01:17 PDT --- *** Issue 6363 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6363] Runtime crashes on a very simple case : throw + dirEntries
http://d.puremagic.com/issues/show_bug.cgi?id=6363 Don changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #2 from Don 2011-08-25 08:01:16 PDT --- Fixed in git master. *** This issue has been marked as a duplicate of issue 6308 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5645] std.range.drop(), std.range.slice()
http://d.puremagic.com/issues/show_bug.cgi?id=5645 --- Comment #5 from Jonathan M Davis 2011-08-25 08:26:01 PDT --- Exactly. Slicing is an O(1) operation, but take(drop(range, 5), 3) is O(n) unless the original range isSliceable. It's perfectly fine to do it, but creating a function such as islice at least implies that it's efficient like slicing is, which isn't generally true. I do have to say though, that it's operations like that that make me wish that take's arguments had never been flipped, so that you could do take(3, drop(5, range)), but I guess that we're stuck at this point, and it made no sense for drop not to match take in regards to the order of its arguments. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6369] alias this doesn't work with initializer
http://d.puremagic.com/issues/show_bug.cgi?id=6369 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 2011-08-25 15:04:17 PDT --- https://github.com/D-Programming-Language/dmd/commit/356593e3fff24bdd3e3bfa742dab52740ce1e595 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6434] opDispatch must be considered before alias this.
http://d.puremagic.com/issues/show_bug.cgi?id=6434 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright 2011-08-25 17:38:45 PDT --- https://github.com/D-Programming-Language/dmd/commit/e3f1fa2d00250d8b94f6ae653c11856a1ea227c0 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6556] New: ICE for ImportStatement in DebugStatement
http://d.puremagic.com/issues/show_bug.cgi?id=6556
Summary: ICE for ImportStatement in DebugStatement
Product: D
Version: D2
Platform: Other
OS/Version: FreeBSD
Status: NEW
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2011-08-25 18:51:20 PDT ---
debug=BUG;
void foo() {
debug(BUG) import anything;
}
---
Import::semantic is assuming that the scope has a scope symbol and
calls importScope on it. It segfaults because debug create a new scope
without symbol. The correct fix seems to be calling importScope on the first
enclosing scope that has a symbol. That way it behaves as
Scope::insert(Dsymbol*).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6556] ICE for ImportStatement in DebugStatement
http://d.puremagic.com/issues/show_bug.cgi?id=6556 --- Comment #1 from d...@dawgfoto.de 2011-08-25 20:09:37 PDT --- https://github.com/D-Programming-Language/dmd/pull/333 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6366] alias this doesn't work with foreach range.front
http://d.puremagic.com/issues/show_bug.cgi?id=6366 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 2011-08-25 20:33:15 PDT --- https://github.com/D-Programming-Language/dmd/commit/4eddacc35f8e8f9c9bba49b222a28a24cc1c51bf -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6543] RDMD -I character limitation
http://d.puremagic.com/issues/show_bug.cgi?id=6543 Nick Sabalausky changed: What|Removed |Added CC||cbkbbej...@mailinator.com --- Comment #1 from Nick Sabalausky 2011-08-25 21:52:00 PDT --- This is likely just an instance of issue 6452. Please check if that's the case by checking RDMD's commandline to DMD with --chatty: rdmd --chatty -I../../../Documents/D/LuaD -L-llua --build-only -ofLuaTest LuaTest.d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
