[Issue 8786] New: assert does not call invariant() function

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8786

   Summary: assert does not call invariant() function
   Product: D
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: major
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com


--- Comment #0 from monarchdo...@gmail.com 2012-10-09 01:19:41 PDT ---
According to http://dlang.org/class.html#Invariant

The invariant can be checked when a class object is the argument to an
assert() expression, as: 

//
Date mydate;
...
assert(mydate); // check that class Date invariant holds
//

But I get:

//
struct S
{
invariant(){}
}

void main()
{
S s;
assert(s);
}
//
Error: expression s of type S does not have a boolean value
//

IMO, behavior of assert should be:
1. Check for argument can be cast to bool. If yes, do it. The call should
trigger invariant check anyways.
2. Else, call invariant directly.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8786] assert does not call invariant() function

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8786


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #1 from bearophile_h...@eml.cc 2012-10-09 01:44:22 PDT ---
This was discussed a lot...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8787] New: Virtual not abstract methods in interfaces error message

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8787

   Summary: Virtual not abstract methods in interfaces error
message
   Product: D
   Version: D2
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: diagnostic
  Severity: minor
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2012-10-09 01:45:24 PDT ---
interface Foo {
void bar() {}
}
void main() {}


DMD 2.061alpha gives:

temp.d(2): Error: function temp.Foo.bar function body is not abstract in
interface Foo

But I suggest an error message like this because final methods are allowed in
D2 interfaces:

temp.d(2): Error: function temp.Foo.bar function body is not abstract or final
in interface Foo

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8786] assert does not call invariant() function

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8786


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmx.com


--- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 01:52:20 
PDT ---
Yes, _class_ object's have their invariant called. You're using a struct. It's
cast to bool (like it would be in the condition of an if statement), and your
struct doesn't define a cast to bool, so it doesn't work.

If you want to check the invariant, then take its address so that you're
operating on a pointer to a struct. In that case, it will act the same way that
a class does.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8784] std.bigint.BigInt.infinity

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8784


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||clugd...@yahoo.com.au
 Resolution||INVALID


--- Comment #1 from Don clugd...@yahoo.com.au 2012-10-09 03:09:45 PDT ---
For floating point numbers of limited size, you need infinity for overflow, and
you can possibly also follow IEEE in generating it for division by zero.
It's more a necessary evil than a desirable feature.

But for BigInt it is quite different. There is no BigInt operation which
results in an overflow, and division by zero is an error. And infinity is a
really, really annoying special case, both in terms of implementation (where it
has a performance penalty) and from the user's side. You have to sacrifice some
important guarantees, eg
assert(x + 1 != x);
is not always true for any type which includes infinity.
That sacrifice doesn't happen for IEEE floating point, since already
   x + 1 == x
for any large number such as real.max / 2, due to reduced precision.
But for BigInt, it's a huge price to pay.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8786] assert does not call invariant() function

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8786


monarchdo...@gmail.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|DMD |websites
   Severity|major   |trivial


--- Comment #3 from monarchdo...@gmail.com 2012-10-09 03:24:37 PDT ---
(In reply to comment #2)
 Yes, _class_ object's have their invariant called. You're using a struct. It's
 cast to bool (like it would be in the condition of an if statement), and your
 struct doesn't define a cast to bool, so it doesn't work.
 
 If you want to check the invariant, then take its address so that you're
 operating on a pointer to a struct. In that case, it will act the same way 
 that
 a class does.

Thanks for the explanation. I was not present when this was discussed a lot,
and the documentation didn't really make it clear.

Anyhow, I took the liberty of updating the documentation.

https://github.com/D-Programming-Language/d-programming-language.org/pulls

Changing to trivial/website/assigned.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8784] std.bigint.BigInt.infinity

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8784



--- Comment #2 from bearophile_h...@eml.cc 2012-10-09 04:00:17 PDT ---
(In reply to comment #1)

 But for BigInt, it's a huge price to pay.

OK. I have templated code that works with integral types, and uses T.max (or
T.infinty if T is a floating point). To make it work with bigints I have to use
a huge_bigint_val or to change the code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8784] std.bigint.BigInt.infinity

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8784



--- Comment #3 from Don clugd...@yahoo.com.au 2012-10-09 05:01:47 PDT ---
(In reply to comment #2)
 (In reply to comment #1)
 
  But for BigInt, it's a huge price to pay.
 
 OK. I have templated code that works with integral types, and uses T.max (or
 T.infinty if T is a floating point). To make it work with bigints I have to 
 use
 a huge_bigint_val or to change the code.

I think it's reasonable to have to change the code. Whenever you use T.max, you
are explicitly using a type with finite representation size. Floating point has
both a T.max and a T.infinity, both of which have different semantics to
integer.max.

Actually I find it difficult to think of non-trivial algorithms which work
correctly even just for built-in integers and built-in floating point. There
isn't much common semantics.

Eg, even sum() needs special treatment. 
sum([real.max, real.max, -real.max, -real.max, 7.0]) == 7.0, not infinity or
NaN.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8788] New: The super constructor call can be prevented by mentioning return.

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8788

   Summary: The super constructor call can be prevented by
mentioning return.
   Product: D
   Version: D1  D2
  Platform: x86_64
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: david.ecka...@sociomantic.com


--- Comment #0 from David Eckardt david.ecka...@sociomantic.com 2012-10-09 
07:20:46 PDT ---
Mentioning a return prevents DMD from rejecting code where a constructor has
an explicit super() call which is done conditionally or not at all. Also it is
possible to return or throw before doing the super() call.
This example code compiles although it should be rejected:
---
class A { this ( ) { } }

class B : A
{
this ( )
{
return;
super();
}

this(int x)
{
try
{
throw new Exception;
super();
}
catch ( ) { }
}

this(float f)
{
if (x == 3)
return;
else
super();
}


this(char c)
{
if (c == 'x')
super();
else
return;
}
}
---
However, if the return statement in the second and third constructor is
omitted, the compile error is triggered correctly.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8788] The super constructor call can be prevented by mentioning return.

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8788



--- Comment #1 from David Eckardt david.ecka...@sociomantic.com 2012-10-09 
07:27:39 PDT ---
Of course the if condition in the third constructor should be f = 3, not x
== 3.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8789] New: mangling of const member function

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8789

   Summary: mangling of const member function
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: zan77...@nifty.com


--- Comment #0 from SHOO zan77...@nifty.com 2012-10-09 07:32:24 PDT ---
Document of mangling for const member function is not completed.
Now, TypeFunction of ABI doesn't consider the const/immutable/shared/inout
attributes.

TypeFunction:
CallConvention FuncAttrs Arguments ArgClose Type

These mangling schemes don't include const/immutable/shared/inout attributes.

If const/immutable/shared/inout attributes are contained in FuncAttrs,
following mangling is wrong:
---
class A
{
void func() const {}
}
pragma(msg, typeof(A.func).mangleof); // xFZv
---
typeof(A.func).mangleof must be FxZv

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8751] Problem with pure inference of inner delegate

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8751


yebblies yebbl...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||yebbl...@gmail.com
 Resolution||FIXED


--- Comment #5 from yebblies yebbl...@gmail.com 2012-10-10 02:32:00 EST ---
https://github.com/D-Programming-Language/dmd/commit/6ecd4f3c9c062d2c297b3dde2f7286314607aa1c

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8644] CTFE doesn't support string , on array literals

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8644


yebblies yebbl...@gmail.com changed:

   What|Removed |Added

 CC||yebbl...@gmail.com
Version|D1  D2 |D1


--- Comment #2 from yebblies yebbl...@gmail.com 2012-10-10 02:35:38 EST ---
Fix for D2:
https://github.com/donc/dmd/commit/8cd8f05dfe1caa050c2995b410d7e73b696cb6ad

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8644] CTFE doesn't support string , on array literals

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8644



--- Comment #3 from github-bugzi...@puremagic.com 2012-10-09 09:12:57 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/8cd8f05dfe1caa050c2995b410d7e73b696cb6ad
Fix bug 8644 - CTFE doesn't support string , on array literals

https://github.com/D-Programming-Language/dmd/commit/f3ee71f1f422fd0ee8863109469f4065a8305b5f
Merge pull request #1114 from donc/ctfe8644_arrayliteralcmp

Fix bug 8644 - CTFE doesn't support string , on array literals

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8644] CTFE doesn't support string , on array literals

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8644



--- Comment #4 from yebblies yebbl...@gmail.com 2012-10-10 03:15:10 EST ---
Whoops.  This is the merge commit.
https://github.com/D-Programming-Language/dmd/commit/f3ee71f1f422fd0ee8863109469f4065a8305b5f

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8751] Problem with pure inference of inner delegate

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8751



--- Comment #6 from bearophile_h...@eml.cc 2012-10-09 10:04:36 PDT ---
This code, that is derived more closely from my use case, gives an error, after
merging the patch:


alias bool delegate(in int) pure Dg;
Dg foo1(immutable Dg f) pure {
return x = f(x); // OK
}
Dg foo2(const Dg f) pure {
return x = f(x); // error
}
void main() {}


DMD patched gives:

temp.d(6): Error: cannot implicitly convert expression (__lambda4) of type bool
delegate(const(int) x) @system to bool delegate(const(int)) pure

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8786] assert does not call invariant() function

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8786



--- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 10:50:32 
PDT ---
The behavior of classes was discussed a lot (in particular, it didn't use to
check whether the reference was null first, which caused a lot of problems).
I'm not sure that the behavior of structs has been discussed much or that it is
necessarily entirely desirable (it's certainly not well-documented), but that's
how it works right now.

Certainly, it makes perfect sense that the struct would be converted to bool.
Whether it should also have its invariant called is debatable, but as long as
the conversion to bool involves calling a public member function, the invariant
will be called anyway. So, the behavior is probably fine.

The fact that the invariant is explicitly checked with a pointer to a struct is
then essentially the same as what happens with classes, so really, the way that
structs currently work with assert is probably the best way to go about it. The
main problem is that it's not necessarily intuitive and that it's not properly
documented. So, if the docs are updated, then it should be fine.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8644] CTFE doesn't support string , on array literals

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8644


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
Version|D1  |D1  D2
 Resolution||FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7772] Remove volatile statements from core.thread

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7772


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||FIXED


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:00:57 
CEST ---
This now done.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7772] Remove volatile statements from core.thread

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7772



--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-09 
17:05:28 PDT ---
Thanks.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8790] New: Compiling with optimization produces erroneous variable initialization error

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8790

   Summary: Compiling with optimization produces erroneous
variable initialization error
   Product: D
   Version: D2
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: regression
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx


--- Comment #0 from hst...@quickfur.ath.cx 2012-10-09 17:41:02 PDT ---
import std.algorithm;
import std.range;

void main() {
auto N2 = sequence!n(cast(size_t)1).map!a;
}


When compiling with dmd -O (latest git for dmd, druntime, phobos), this
produces the following errors:

/usr/src/d/phobos/std/range.d(4590): Error: variable upper used before set
/usr/src/d/phobos/std/range.d(4590): Error: variable lower used before set

The referenced line of code occurs in this context:

auto opSlice(size_t lower, size_t upper)
in
{  
assert(upper = lower); // this is line 4590
}
body
{  
auto s = typeof(this)(this._state, this._n + lower);
return takeExactly(s, upper - lower);
}

Which makes no sense, because there is nothing wrong with the reference to
upper and lower (they are function parameters). Perhaps the optimizer
inadvertently permuted the order of stuff in a way that caused the contract to
run before the parameters are initialized?

If -O is not specified, the compile is successful. This problem appears to be
independent of whether I specify -m32 or -m64.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 2563] Derived class is implicitly castable to Base class when inherited privately

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2563


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||WONTFIX


--- Comment #9 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:41:02 
CEST ---
Considering D1 is close to being discontinued and this feature is long
deprecated in D2, I think it's safe to close this. I don't see anyone ever
getting around to fixing it, so keeping it open is somewhat pointless.

(Feel free to reopen if you disagree.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 1335] typedef-1 can't be stored in same typedef

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1335


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||WONTFIX


--- Comment #7 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:42:06 
CEST ---
Closing since typedef is effectively deprecated.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8791] New: Optlink fails when reading PATH variable and -g is used

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8791

   Summary: Optlink fails when reading PATH variable and -g is
used
   Product: D
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: blocker
  Priority: P2
 Component: Optlink
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com


--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-09 
17:42:15 PDT ---
Minimal test-case on WinXP:
test.d:
void main() { }

$ set PATH=D:\DMD\dmd2\windows\bin;C:\Fake+-Dir
$ dmd -g test.d

OPTLINK (R) for Win32  Release 8.00.12
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Error 118: Filename Expected
Path=D:\DMD\dmd2\windows\bin;C:\Fake+-Dir
^
--- errorlevel 1

GTK3 by default installs to C:\Program Files\GTK+-Bundle-3.4.2\bin, which
breaks Optlink when compiling with -g.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8727] __traits(is_reserved_word, ) ?

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8727


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


--- Comment #5 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:46:53 
CEST ---
OK, I think this can be implemented as a library trait.

Anyone want to send a pull request that adds it to std.traits?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6909] incorrect definition of the OVERLAPPED struct in core.sys.windows.windows ?

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6909


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||FIXED


--- Comment #4 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:48:14 
CEST ---
The definition is correct in druntime now.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7112] Add function in core.sys.posix.signal

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7112


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||a...@lycus.org
 AssignedTo|nob...@puremagic.com|a...@lycus.org


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:54:59 
CEST ---
This needs to be added to a separate signalfd header module for Linux only.
I'll look into it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7112] Add function in core.sys.posix.signal

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7112


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

   Keywords||pull


--- Comment #2 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:11:14 
CEST ---
https://github.com/D-Programming-Language/druntime/pull/315

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5562] Add OS=win32wine build to druntime's posix.mak

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5562


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:14:39 
CEST ---
Can you provide a patch for this? I imagine porting over the stuff from the
Phobos posix.mak shouldn't be too hard, but I don't have a Wine environment to
test with.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5593] Add dladdr to druntime for linux/FreeBSD

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5593


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||a...@lycus.org
 AssignedTo|nob...@puremagic.com|a...@lycus.org


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8791] Optlink fails when reading PATH variable and -g is used

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8791


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com


--- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-10-09 
18:23:02 PDT ---
Try enclosing the path in  .

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5593] Add dladdr to druntime for linux/FreeBSD

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5593


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

   Keywords||pull


--- Comment #3 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:23:07 
CEST ---
https://github.com/D-Programming-Language/druntime/pull/316

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6038] core.cpuid reports unexpected values for threadsPerCPU and hyperThreading

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6038


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||FIXED


--- Comment #5 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:27:58 
CEST ---
Closing since the pull request was merged (and other comments speculation still
:).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8791] Optlink fails when reading PATH variable and -g is used

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8791



--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-09 
18:27:51 PDT ---
(In reply to comment #1)
 Try enclosing the path in  .

Doesn't help.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5589] Incorrect definitions in core.stdc.locale (Windows)

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5589


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:28:26 
CEST ---
I'm not sure what header you're going by. The MSVC one or the Digital Mars one?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6649] core.sys.posix.sys.ioctl

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6649


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||a...@lycus.org
 AssignedTo|nob...@puremagic.com|a...@lycus.org


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8418] core.thread.Fiber is a Coroutine or Semi-Coroutine?

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8418


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:34:06 
CEST ---
Can you please send a pull request with a doc fix? You probably know the API
better than I do.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7971] Cannot compile druntime with -debug=PRINTF

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7971


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8273] FreeBSD core.sys.posix.unistd enums severely lacking

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8273


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||a...@lycus.org
 AssignedTo|nob...@puremagic.com|a...@lycus.org


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3057] Add pure annotations to core.stdc.*

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3057


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||FIXED


--- Comment #13 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:35:57 
CEST ---
I sent a pull request a while back that added safety, purity, and nothrow
annotations throughout core.stdc (not having noticed the patch here). I'll
close this, but if it turns out I forgot some annotations, please reopen.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3696] SuperStack

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3696


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||WONTFIX


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:42:22 
CEST ---
Let's open an issue if there is actual interest or someone provides a patch.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8633] core.atomic not documented

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8633


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

   Keywords||pull
 Status|NEW |ASSIGNED
 CC||a...@lycus.org
 AssignedTo|nob...@puremagic.com|a...@lycus.org


--- Comment #2 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:40:03 
CEST ---
https://github.com/D-Programming-Language/druntime/pull/317

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4332] C files in druntime should be converted to D

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4332


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||FIXED


--- Comment #16 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:43:03 
CEST ---
This is now done.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4255] Missing declaration on core.stdc.stdio of kbhit function

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4255


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||WONTFIX


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:44:41 
CEST ---
kbhit by itself is not standardized and _kbhit is apparently ISO C++.
core.stdc.* only binds C99. So, closing this...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4222] druntime should apply @safe/@system/@trusted

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4222


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||a...@lycus.org
 AssignedTo|s...@invisibleduck.org  |a...@lycus.org


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:45:37 
CEST ---
This is something I'll be working on over the next weeks/months. I have a bit
of a monster patch already in-review that needs to be rebased.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4848] core.sys.windows.windows: Environment functions

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4848


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||FIXED


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:46:44 
CEST ---
These are now present.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 4862] modfl() missing for FreeBSD

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4862


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #2 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:47:40 
CEST ---
Is this still an issue? And if so, what do we need to do about it?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6024


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #19 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:49:22 
CEST ---
Please submit a pull request to the dpl.org repo so we can get this out of the
way. :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5057] std.variant.Algebraic-aware GC

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5057


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lycus.org
 Resolution||WONTFIX


--- Comment #5 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:51:55 
CEST ---
Let us revisit this if it ever becomes a problem in practice; I very much doubt
it. At any rate, special-casing it in the GC is the wrong kind of design.

I'll also add that I'm against adding GC heap allocation to Variant/Algebraic
as this would severely slow down code that uses many instances of these types
for no good reason.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5206] stat_t is not the same as struct stat

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5206


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #13 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:52:38 
CEST ---
Can we close this?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3523] Fiber is not garbage collected properly

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3523


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #12 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:54:02 
CEST ---
What is the status of this today?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6151] Make the GC functions weakly pure

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6151


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:53:28 
CEST ---
What we really need in order to move forward with this is a way to explicitly
tell the compiler that something is weakly pure.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3696] SuperStack

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3696



--- Comment #2 from Chad Joan chadj...@gmail.com 2012-10-09 19:08:23 PDT ---
(In reply to comment #1)
 Let's open an issue if there is actual interest or someone provides a patch.

I still want this.  I don't know how to implement it efficiently and I haven't
used it because it doesn't exist :/

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3696] SuperStack

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3696



--- Comment #3 from Alex R�nne Petersen a...@lycus.org 2012-10-10 04:19:20 
CEST ---
Well, at some point, we have to close enhancement requests because nobody's
worked on them. The 'WONTFIX' resolution was not to say it can't/shouldn't be
done, but just a reflection of the fact that any core developers are unlikely
to work on this (at least right now).

By all means, reopen if someone starts work on this. :)

(Besides, this should probably be filed against Phobos, not DRuntime.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3696] SuperStack

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3696



--- Comment #4 from Chad Joan chadj...@gmail.com 2012-10-09 19:21:01 PDT ---
(In reply to comment #3)
 Well, at some point, we have to close enhancement requests because nobody's
 worked on them. The 'WONTFIX' resolution was not to say it can't/shouldn't be
 done, but just a reflection of the fact that any core developers are unlikely
 to work on this (at least right now).
 
 By all means, reopen if someone starts work on this. :)
 
 (Besides, this should probably be filed against Phobos, not DRuntime.)

Makes sense.  Thank you.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8790] Compiling with optimization produces erroneous variable initialization error

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8790


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jmdavisp...@gmx.com
 Resolution||DUPLICATE


--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 19:22:06 
PDT ---
I believe that this is a duplicate of bug# 8556. I suspect that at least part
of the problem is that takeExactly checks hasSlicing, so if you're using
takeExactly to do slicing, it's going to cause problems right now. I'm almost
finished on a pull request which will fix that, and that may or may not make it
so that this bug doesn't manifest itself with sequence, but if anything, that
means that we'd need to find another way to reproduce this bug, because that
will just fix the Phobos part, not the compiler bug.

*** This issue has been marked as a duplicate of issue 8556 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8556] Using take results in a corrupted call to opSlice

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8556


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx


--- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 19:22:06 
PDT ---
*** Issue 8790 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 8556] Using take results in a corrupted call to opSlice

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8556


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

   Severity|blocker |regression


--- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 19:23:44 
PDT ---
I'm changing this to a regression, because bug# 8790 shows an example of where
this causes a regression:

import std.algorithm;
import std.range;

void main() {
auto N2 = sequence!n(cast(size_t)1).map!a;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8730] writeln stops on a nul character, even if passed a D string

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8730



--- Comment #2 from Adam D. Ruppe destructiona...@gmail.com 2012-10-09 
19:24:49 PDT ---
(In reply to comment #1)
 The specialization is probably to blame. I think 'args[0].length' probably 
 sets
 the max limit rather than min, but I don't know enough about fprintf 
 internals.
 :)


Yeah, you're right. The man page for printf says the maximum number of
   characters to be printed from a string for s and S conversions.


I'm not sure what is best here. I really think it should work, but the
specialization has got to be there for a reason too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5057] std.variant.Algebraic-aware GC

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5057



--- Comment #6 from bearophile_h...@eml.cc 2012-10-09 19:28:00 PDT ---
(In reply to comment #5)
 Let us revisit this if it ever becomes a problem in practice; I very much 
 doubt
 it. At any rate, special-casing it in the GC is the wrong kind of design.
 
 I'll also add that I'm against adding GC heap allocation to Variant/Algebraic
 as this would severely slow down code that uses many instances of these types
 for no good reason.

I agree that special casing for Algebraic is probably too much.

But GC precision is a problem, especially on 32 bit system. 

And here I was not discussing about allocating an Algebraic on the heap, but
the problems caused by putting references to heap-allocated things inside an
Algebraic. So it's a problem shared by all unions. The idea of onScan is
general, it's not a special case for Algebraic, it's usable to help the GC for
all unions (but it's especially useful for Algebraic because it has a tag).

Maybe I will open an enhancement request about all unions...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5057] std.variant.Algebraic-aware GC

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5057



--- Comment #7 from Alex R�nne Petersen a...@lycus.org 2012-10-10 04:33:54 
CEST ---
(In reply to comment #6)
 (In reply to comment #5)
  Let us revisit this if it ever becomes a problem in practice; I very much 
  doubt
  it. At any rate, special-casing it in the GC is the wrong kind of design.
  
  I'll also add that I'm against adding GC heap allocation to 
  Variant/Algebraic
  as this would severely slow down code that uses many instances of these 
  types
  for no good reason.
 
 I agree that special casing for Algebraic is probably too much.
 
 But GC precision is a problem, especially on 32 bit system. 

Absolutely.

 
 And here I was not discussing about allocating an Algebraic on the heap, but
 the problems caused by putting references to heap-allocated things inside an
 Algebraic. So it's a problem shared by all unions. The idea of onScan is
 general, it's not a special case for Algebraic, it's usable to help the GC for
 all unions (but it's especially useful for Algebraic because it has a tag).

My comments about heap allocations were not directed at you, but at
nfx...@gmail.com.

One very trivial way that Algebraic can be made more GC friendly is by making
it inspect all types that it can represent - if none of them are
references/pointers, signal this to the GC accordingly.

It doesn't handle the case where a variant can have both non-GC'd and GC'd
types, but I think that this is very rare compared to variants with exclusively
GC'd types and variants with exclusively non-GC'd types.

 
 Maybe I will open an enhancement request about all unions...

I imagine unions in general will be a pain for the new precise GC. But let's
wait and see how it handles this problem before we open another issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8730] writeln stops on a nul character, even if passed a D string

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8730



--- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-09 
19:38:15 PDT ---
(In reply to comment #2)
 (In reply to comment #1)
  The specialization is probably to blame. I think 'args[0].length' probably 
  sets
  the max limit rather than min, but I don't know enough about fprintf 
  internals.
  :)
 
 
 Yeah, you're right. The man page for printf says the maximum number of
characters to be printed from a string for s and S conversions.
 
 
 I'm not sure what is best here. I really think it should work, but the
 specialization has got to be there for a reason too.

It could me off guard just recently. E.g. git uses two strings separated by nul
in it's object format, and when I've tried to print out the contents as a
char[] using writeln it would only print out a small portion of it, even though
printing it as a byte[] would print much more.

Anyway this *is* a bug. We can't have it both ways:
writeln(bla\0bla);  // bla
writefln(%s, bla\0bla);  // bla[NUL]bla

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6649] core.sys.posix.sys.ioctl

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6649


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

   Keywords||pull


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 04:39:06 
CEST ---
https://github.com/D-Programming-Language/druntime/pull/318

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8792] New: std.algorithm.joiner doesn't return a proper forward range`

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8792

   Summary: std.algorithm.joiner doesn't return a proper forward
range`
   Product: D
   Version: D2
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx


--- Comment #0 from hst...@quickfur.ath.cx 2012-10-09 20:25:31 PDT ---
import std.algorithm;
import std.range;
import std.stdio;

void main() {
auto x = [[1],[2],[3]];
auto yy = x.joiner;

assert(isForwardRange!(typeof(yy)));
writeln(yy.save);
writeln(yy);
}

The output is:

[]
[1, 2, 3]

Which means that yy.save didn't save at all! This is a pretty major bug since
it makes joiner unusable where the result needs to be a forward range.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8730] writeln stops on a nul character, even if passed a D string

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8730


Brad Roberts bra...@puremagic.com changed:

   What|Removed |Added

 CC||bra...@puremagic.com


--- Comment #4 from Brad Roberts bra...@puremagic.com 2012-10-09 20:33:42 PDT 
---
Shouldn't this be trivial to fix:

Replace:
fprintf(.stdout.p.handle, %.*s\n,
cast(int) args[0].length, args[0].ptr)

with:
fwrite(args[0].ptr, 1, args[0].length, .stdout.p.handle)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8730] writeln stops on a nul character, even if passed a D string

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8730



--- Comment #5 from Brad Roberts bra...@puremagic.com 2012-10-09 20:36:53 PDT 
---
oops, followed by the same code as in the length == 0 code to get the \n.  At
which point it's questionable that specialization is all that special.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8556] Using take results in a corrupted call to opSlice

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8556



--- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 20:52:16 
PDT ---
Okay. Here's a test case which does not rely on either take, takeExactly or
hasSlicing (since they will likely be changed soon so that they don't have a
circular dependency, fixing the immediate problem in Phobos but not fixing the
compiler bug):

import std.algorithm;
import std.range;
import std.stdio;
import std.string;
import std.traits;

template isSliceable(R)
{
enum bool isSliceable = !isNarrowString!R  is(typeof(
(inout int _dummy=0)
{
R r = void;
auto s = r[1 .. 2];
static assert(isInputRange!(typeof(s)));
}));
}

struct Grab(Range)
if (isInputRange!(Unqual!Range)
 !(isSliceable!(Unqual!Range) || is(Range T == Grab!T)))
{
private alias Unqual!Range R;

// User accessible in read and write
public R source;

private size_t _maxAvailable;
private enum bool byRef = is(typeof(_input.front) == ElementType!(R)*);

alias R Source;

@property bool empty()
{
return _maxAvailable == 0 || source.empty;
}

@property auto ref front()
{
assert(!empty,
Attempting to fetch the front of an empty 
~ Grab.stringof);
return source.front;
}

void popFront()
{
assert(!empty,
Attempting to popFront() past the end of a 
~ Grab.stringof);
source.popFront();
--_maxAvailable;
}

static if (isForwardRange!R)
@property Grab save()
{
return Grab(source.save, _maxAvailable);
}


static if (isInfinite!R)
{
@property size_t length() const
{
return _maxAvailable;
}

alias length opDollar;
}
else static if (hasLength!R)
{
@property size_t length()
{
return min(_maxAvailable, source.length);
}

alias length opDollar;
}
}

Grab!R grab(R)(R input, size_t n)
if (isInputRange!(Unqual!R)  isSliceable!(Unqual!R))
{
static if (hasLength!R)
return input[0 .. min(n, input.length)];
else
return input[0 .. n];
}

Grab!(R) grab(R)(R input, size_t n)
if (is(R T == Grab!T))
{
return R(input.source, min(n, input._maxAvailable));
}

Grab!R grab(R)(R input, size_t n)
if (isInputRange!(Unqual!R)  !isSliceable!(Unqual!R)  !is(R T == Grab!T))
{
return Grab!R(input, n);
}

auto grabExactly(R)(R range, size_t n)
if (isInputRange!R  !isSliceable!R)
{
static if (is(typeof(grabExactly(range._input, n)) == R))
{
range._n = n;
return range;
}
else
{
static struct Result
{
R _input;
private size_t _n;

@property bool empty() const { return !_n; }
@property auto ref front()
{
assert(_n  0, front() on an empty  ~ Result.stringof);
return _input.front();
}
void popFront() { _input.popFront(); --_n; }
@property size_t length() const { return _n; }
alias length opDollar;

static if (isForwardRange!R)
@property auto save() { return this; }
}

return Result(range, n);
}
}

auto grabExactly(R)(R range, size_t n)
if (isSliceable!R)
{
return range[0 .. n];
}

struct Circle(Range)
if (isForwardRange!(Unqual!Range)  !isInfinite!(Unqual!Range))
{
alias Unqual!Range R;

R _original;
size_t _index;

this(R input, size_t index = 0) { _original = input; _index = index; }

@property auto ref front()
{
return _original[_index % _original.length];
}

enum bool empty = false;

void popFront() { ++_index; }

auto opSlice(size_t i, size_t j)
{
assert(j = i, format(%s %s %s, i, j, _index));
writefln(%s %s %s, i, j, _index);
return grabExactly(typeof(this)(_original.save, _index + i), j - i);
}
}

Circle!R circle(R)(R input, size_t index = 0)
if (isRandomAccessRange!(Unqual!R)  !isInfinite!(Unqual!R))
{
return Circle!R(input, index);
}

void main()
{
uint[] arr = [1U, 2U, 3U, 4U, 5U, 6U, 7U, 8U, 9U, 10U];
auto t = grab(circle(arr), 20);

auto cx = circle(arr);
auto slice = cx[23 .. 33];
assert(equal(slice, [4, 5, 6, 7, 8, 9, 10, 1, 2, 3]), format(%s,
array(slice)));
}

It can probably be reduced further, but that already reduces it a fair bit.
It's been copied from Phobos with the names being tweaked (hasSlicing -
isSliceable, take - grab, takeExactly - grabExactly) and some of the
unnecessary parts stripped out. So, this should provide a reproducible test
case even once hasSlicing and take have been fixed. I believe that the key
thing is the circular dependencies involved.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7992] std.algorithm.find breaks in certain circumstances

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7992


hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx


--- Comment #2 from hst...@quickfur.ath.cx 2012-10-09 20:55:47 PDT ---
OK, something is very broken in simpleMindedFind(). When both haystack and
needle have the length property, estimateNeedleLength is set to false, and
estimatedNeedleLength is set to 0. Therefore, haystackTooShort() is always
false.

So in the searching loop, the if(haystackTooShort()) is skipped, and it falls
straight through to the for(auto h=haystack.save;...) loop. But here, if
h.empty is true, then because estimateNeedleLength is false, this goes straight
to continue searching, which calls popFront() on an empty range.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 7992] std.algorithm.find breaks in certain circumstances

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7992



--- Comment #3 from hst...@quickfur.ath.cx 2012-10-09 21:31:44 PDT ---
https://github.com/D-Programming-Language/phobos/pull/852

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8792] std.algorithm.joiner doesn't return a proper forward range

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8792



--- Comment #1 from hst...@quickfur.ath.cx 2012-10-09 22:15:59 PDT ---
Found the bug: joiner.Result.save didn't copy 1 field over, so the saved range
is defective.

https://github.com/D-Programming-Language/phobos/pull/853

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8513] Cannot use dot for base class lookup in inheritance list

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8513


yebblies yebbl...@gmail.com changed:

   What|Removed |Added

   Keywords||pull, rejects-valid
 CC||yebbl...@gmail.com
Version|D2  |D1  D2


--- Comment #1 from yebblies yebbl...@gmail.com 2012-10-10 16:25:55 EST ---
https://github.com/D-Programming-Language/dmd/pull/1160

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 1352] Can't use module scope operator in base class list.

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1352


yebblies yebbl...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||yebbl...@gmail.com
 Resolution||DUPLICATE


--- Comment #1 from yebblies yebbl...@gmail.com 2012-10-10 16:26:27 EST ---
*** This issue has been marked as a duplicate of issue 8513 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8513] Cannot use dot for base class lookup in inheritance list

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8513


yebblies yebbl...@gmail.com changed:

   What|Removed |Added

 CC||aziz.koek...@gmail.com


--- Comment #2 from yebblies yebbl...@gmail.com 2012-10-10 16:26:27 EST ---
*** Issue 1352 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 8714] Missing error message with circular use of CTFE

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8714



--- Comment #2 from github-bugzi...@puremagic.com 2012-10-09 22:33:00 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/4eb179d96c4b3402250a707e29ca00ca982cd431
Fix issue 8714 Missing error message with circular use of CTFE

The error message was missing, and the supplementary error was also
spuriously repeated.

https://github.com/D-Programming-Language/dmd/commit/649ad799371e282391813ba9126f5f63f4223656
Merge pull request #1141 from donc/ctfe8714recursive_semantic

Fix issue 8714 Missing error message with circular use of CTFE

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8714] Missing error message with circular use of CTFE

2012-10-09 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8714


yebblies yebbl...@gmail.com changed:

   What|Removed |Added

 CC||yebbl...@gmail.com
Version|D2  |D1


--- Comment #3 from yebblies yebbl...@gmail.com 2012-10-10 16:34:37 EST ---
Fixed for D2

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---