date:20160304

[Issue 15764] Name lookup within (eponymous?) template doesn't check outside the template

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15764

Shriramana Sharma  changed:

   What|Removed |Added

Summary|Name of template cannot |Name lookup within
   ||(eponymous?) template
   ||doesn't check outside the
   ||template

--

[Issue 15764] New: Name of template cannot

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15764

  Issue ID: 15764
   Summary: Name of template cannot
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: samj...@gmail.com

Ref: http://forum.dlang.org/post/nb8kkg$1ea0$1...@digitalmars.com

string ta(string s) { return s ~ "1"; }
template ta(string s) { enum ta = .ta(s); }
void main()
{
import std.stdio;
writeln(ta("a"), ' ', ta!"b");
}

outputs "a1 b1" as expected. So the compiler is in general able to identify
when a symbol refers to a function and when a template, but if I remove the .
before the ta(s) *within* the template ta, it gives an error:

(2): Error: forward reference of variable ta
(6): Error: template instance .ta!"b" error instantiating

This seems to be a minor limitation (and maybe not of terribly high priority)
that symbol lookup within an (eponymous?) template doesn't look outside the
template for other possible compatible symbols and requires a preceding "." to
tell it to look at top-level.

--

[Issue 15761] Windows wide character console output broken with MS runtime

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15761

--- Comment #1 from Martin Krejcirik  ---
OK, after some experimenting, at looks like even UTF8 has serious problems
(ErrnoException from Phobos), is it really so much broken on Windows ?

--

[Issue 15763] New: std.math.approxEqual is not symmetric

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15763

  Issue ID: 15763
   Summary: std.math.approxEqual is not symmetric
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: r.97...@gmail.com

Current implementation of std.math.approxEqual is not symmetric.  The code
below gives an example.


import std.math : eq = approxEqual;
immutable real
a = (2e-3)-(1e-5),
b = (2e-3)+(1e-5);
assert ( a.eq(b)); // (error relative to b) = 1 / (100.5)
assert (!b.eq(a)); // (error relative to a) = 1 / ( 99.5)


IMO at least we need to document this.  It may be enough since the case this
asymmetricity do something harm is rare.

If we "fix" it, we must consider the backward compatibility, and/or
performance.

I would be pleased with an alternative for approxEqual like this:


return ((a - b).abs < abserr) || ((a - b).abs / (a.abs + b.abs) < relerr / 2);

Any opinion?

--

[Issue 15762] New: Array casts involving const enums can be made @safe

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15762

  Issue ID: 15762
   Summary: Array casts involving const enums can be made @safe
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dhase...@gmail.com

According to dmd 2.070.0:

enum Windows1252Char : ubyte { init }

void main() @safe {
ubyte[] a = [1, 2, 3, 4];
auto aw = cast(Windows1252Char[]) a;  // valid
auto caw = cast(const(Windows1252Char)[]) a;  // valid
const(ubyte)[] c = [1, 2, 3, 4];
auto d = cast(const(Windows1252Char)[]) c;// invalid
}

arrcast.d(9): Error: cast from const(ubyte)[] to const(Windows1252Char)[] not
allowed in safe code

The compiler is fine if I cast mutable to mutable, or mutable to const, but I
can't cast const to const. Why not?

Switching from an enum type to a builtin type or struct makes things work, so
this looks like an oversight.

Context: I'm trying to make a @safe version of std.encoding, which does a ton
of casting between array types. I have to make much more code @trusted than I'd
like, and allowing const(ubyte) -> const(enum) casts would lead to far less
@trusted code.

--

[Issue 15639] std.experimental.allocator enables abstract class instantiation

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15639

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 15639] std.experimental.allocator enables abstract class instantiation

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15639

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/175b9129a0293667371027fa68b85d9e7c78754e
fixed issue 15639

https://github.com/D-Programming-Language/phobos/commit/3edc09dfa4d4e6223409316d2dcde6d3fdec7066
Merge pull request #4023 from BBasile/ussue-15639

fixed issue 15639 - allocator.make enables abstract class instantiation

--

[Issue 15761] New: Windows wide character console output broken with MS runtime

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15761

  Issue ID: 15761
   Summary: Windows wide character console output broken with MS
runtime
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: m...@krej.cz

import std.stdio, core.sys.windows.windows;

void main()
{
SetConsoleOutputCP(65001);

writeln("1 ááá");
writeln("2 ááá"w); // broken with -m32mscoff and -m64
writeln("3 ááá"d); // broken with -m32mscoff and -m64
}

--

[Issue 15760] Segfault when compiling when using __gshared and selective import.

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15760

--- Comment #1 from Christian D  ---
*bar instead of boo

--

[Issue 15760] New: Segfault when compiling when using __gshared and selective import.

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15760

  Issue ID: 15760
   Summary: Segfault when compiling when using __gshared and
selective import.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: asistentedeprincipi...@gmail.com

#cat alice.d

import bob : Foo;

struct Bar {
__gshared Foo foo;
}

#cat bob.d
import alice;

struct Foo {
Bar a;
}

Compiling with dmd, gdc or ldc causes a segmentation fault.

'dmd alice.d bob.d' segfaults, but 'dmd bob.d alice.d' doesn't.
Changing the first import from 'bob : Foo' to just 'bob' stops the segfault.
Also happens if foo is a pointer but if boo is one, it doesn't have the
problem.

--

[Issue 6621] Superimposition amount for std.range.chunks

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=6621

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #3 from greenify  ---
See also

Sliding window (repeats previous chunks):

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

std.range.chunks with mere input ranges (buffered)

https://issues.dlang.org/show_bug.cgi?id=15759

--

[Issue 15759] New: chunks should work with only an input range

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15759

  Issue ID: 15759
   Summary: chunks should work with only an input range
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greeen...@gmail.com

It would be nice if `chunks` would accept only an InputRange too. Let me show
you a common pattern that I often use:

// iterate over two lines in a pair and compute the difference between them
// 1 2
// 2 3
// => 2
stdin.byLineCopy.map!(x => x.splitter(' ').map!(to!int)).chunks(2)).map(x =>
  abs(x.frontPop - x.front);
);

This currently doesn't compile, because `chunks` doesn't buffer, it saves the
state of the forward range. However adding support for normal Input Ranges
shouldn't can easily done using a local buffer - I already wrote the code at
some point:

https://github.com/greenify/d-itertools/blob/4afbc804e8b50c797fa206969dc3b4934911a0b9/source/splitwise.d

I would be happy to wrap this up nicely and bring it into a phobos shape - any
thoughts/concerns?

--

[Issue 15758] New: .deb not installing on Ubuntu 15.10 since 2.7x was released.

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15758

  Issue ID: 15758
   Summary: .deb not installing on Ubuntu 15.10 since 2.7x was
released.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: fischer_m...@lycos.com

Have been hoping this would be patched soon -- but Package Installer on Ubuntu
15.10 is reporting:

Lintian check results for /temp/dmd_2.070.0-0_amd64.deb:

Can't close(GLOB(0x184a0e0)) filehandle: '' at
/usr/share/lintian/helpers/coll/objdump-info-helper line 192
command failed with error code 123 at
/usr/share/lintian/collection/objdump-info line 79.
warning: collect info objdump-info about package dmd failed
warning: skipping check of binary package dmd

Likewise for dmd_2.070.1-0_amd64.deb, dmd_2.070.2-0_amd64.deb

--

[Issue 15755] DMD segfault upon alias on alias on __trait(getAttributes, ...)

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15755

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||ice
 CC||ag0ae...@gmail.com

--

[Issue 15757] New: D main is a nested function and cannot be accessed

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15757

  Issue ID: 15757
   Summary: D main is a nested function and cannot be accessed
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: jesse.k.phillip...@gmail.com

I feel as though the code below should compile. If I move the inner struct "M"
out of the scope of test() it compiles just fine.

---
import std.algorithm;

void main() @safe
{
[1,2,3].map!(x => x*x).test;
}

void test(R)(R r) {
struct M(R) {
@disable this();
this(R r) {
payload = r;
}
R payload;
}

M!R m = M!R(r);
}
---
$ dmd test.d
test.d(17): Error: function D main is a nested function and cannot be accessed
from test.test!(MapResult!(__lambda1, int[])).test
---

--

[Issue 12318] Nested structs with only templated methods do not capture context

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=12318

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #1 from John Colvin  ---
I just hit this as well, it's a pain.

--

[Issue 15753] clear method for AA not work

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15753

--- Comment #4 from Steven Schveighoffer  ---
OK, thanks.

As I said, 2.071 will have this feature. Sorry the documentation was released
too early.

--

[Issue 15753] clear method for AA not work

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15753

--- Comment #3 from yosik...@altalk.com ---
(In reply to Steven Schveighoffer from comment #1)
> This is a recent addition. What compiler/version are you using?

>dmd --version
DMD32 D Compiler v2.070.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright

-- aki.

--

[Issue 15753] clear method for AA not work

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15753

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Steven Schveighoffer  ---
Actually, latest release (2.070) does not have this. It's only in master. I
don't know why the site documentation is updated early. It will be present in
2.071.

--

[Issue 15753] clear method for AA not work

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15753

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
This is a recent addition. What compiler/version are you using?

--

[Issue 15285] Range-ified functions for std.string

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15285

--- Comment #5 from Jonathan M Davis  ---
> So you mean we could add to isSomeString a RangeString?

I mean something like

if(isInputRange!Range &&
   isSomeChar!(ElementEncodingType!Range) &&
   !isConvertibleToString!Range)
{
}

which is what some of the functions in std.string already have. In some cases,
a bidirectional or random-acesss range might be required, but it's a range of
char, wchar, or dchar that isn't an array.

> 1) can we replace for --> foreach or do we have to use `static if`?

That would depend entirely on the function. In many cases, you'd probably end
up with a different overload. For instance, that's what indexOf did. Some of
its overloads operate on strings, whereas others operate on aribtrary ranges of
characters.

> 2) we still will return a newly allocated immutable string. Should we return 
> something different for ranges?

That would depend on the function. If the function is supposed to return a
newly allocated string, then that's probably what it's going to need to do, but
in some cases, it may be able to return the original range (or a slice of it),
and most functions that return a newly allocated array should eventually have a
counterpart that returns another range type so that it can avoid allocations.

But essentially, what we want is for the functions in std.string to operate on
arbitrary ranges of characters in a way that's compatible with the current API.
Generic code will need to work the same way with these functions whether
they're taking strings or ranges. But exactly what needs to happen is going to
depend on the function in question, and we'll have to look at that on a case by
case basis.

--

[Issue 15756] New: reading wrong address for alias in nested struct instance

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15756

  Issue ID: 15756
   Summary: reading wrong address for alias in nested struct
instance
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

void main()
{
import std.stdio;
long a = 4;
writeln(a);  // 4
writeln(); // 7FBFE6BAA0

struct Blah
{
alias b = a;
}
Blah blah;

writeln(Blah.b);// 4
writeln(&(Blah.b)); // 7FBFE6BAA0
writeln(blah.b);// 1075983360
writeln(&(blah.b)); // 7FBFE6BAA8
}

--

[Issue 6974] [AA] Associative array with enum array keys is slow

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=6974

Cédric Picard  changed:

   What|Removed |Added

 CC||cpic...@openmailbox.org

--

[Issue 15753] clear method for AA not work

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15753

Cédric Picard  changed:

   What|Removed |Added

 CC||cpic...@openmailbox.org

--

[Issue 15755] DMD segfault upon alias on alias on __trait(getAttributes, ...)

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15755

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #1 from Ketmar Dark  ---
it segfaults when it tries to print this error inside `hasNestedArgs` in
dtemplate.d:

error("%s is nested in both %s and %s", toChars(), enclosing.toChars(),
dparent.toChars());

somehow it ends in "nested" checks with `Dsymbol dparent = sa.toParent2();` as
`null`, and don't bother to double-check if template really has any parent.

it seems that adding a simple check there doesn't really breaks anything (it
shouldn't! ;-), so it can be used as workaround until the real fix will be
done.

--

[Issue 15285] Range-ified functions for std.string

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15285

--- Comment #4 from greenify  ---
Hey I had a look at what types does functions allow:

abbrev  string[]
capitalize  isSomeString
isNumeric   isSomeString
inPattern   isSomeString
munch   isSomeString  
representation  Char[] (char[],wchar[],dchar[])
squeeze anything - no constrains???
succisSomeString
translate   immutable char[]
outdent isSomeString
wrapisSomeString

I guess the biggest win is, if we first focus on those isSomeString functions.

So you mean we could add to isSomeString a RangeString?

```
template isRangeString(R)
{
enum bool isRangeString = is(typeof(
(inout int = 0)
{
static assert(isInputRange!R);
static assert(hasLength!R); // all the algorithms allocate a new
immutable string
static asssert(isSomeChar!(isElementType!R));
}
}
```

The only problem then would be that currently those algorithms use an
index-based for-loop

```
for (size_t i = j; i < iLen; i++)
{
immutable c = s[i];
```

can we just replace that with 

```
   foreach (i,immutable c;s)
```

so in summary - my questions:

1) can we replace for --> foreach or do we have to use `static if`?
2) we still will return a newly allocated immutable string. Should we return
something different for ranges?

--

[Issue 15742] parseJSON does not work at compile time for JSON input with object of object or array of array

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15742

Tomoya Tanjo  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Tomoya Tanjo  ---
I confirmed it works on master. Thanks!

--

[Issue 15755] New: DMD segfault upon alias on alias on __trait(getAttributes, ...)

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15755

  Issue ID: 15755
   Summary: DMD segfault upon alias on alias on
__trait(getAttributes, ...)
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: iamtakingite...@eientei.org

The following code segfaults dmd 2.070 on current master HEAD :
07217cc3e05d465dff8341cf90f7710b94e02070 :

--->3---
struct Foo {
@(123)
int a;
}

template Attributes(As...) {
alias Attributes = As;
}

template getattribute(alias member, alias attrs =
Attributes!(__traits(getAttributes, member))) {
alias getattribute = attrs;
}

void main() {
getattribute!(__traits(getMember, Foo, "a"));
}
--->3---

Result: Compilation error  / Return code: 11 (Segmentation fault)

--

[Issue 15726] [REG2.068.0] forward reference error for circular classes, RefCounted

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15726

Kenji Hara  changed:

   What|Removed |Added

   Hardware|x86 |All
Summary|forward reference error for |[REG2.068.0] forward
   |circular classes,   |reference error for
   |RefCounted  |circular classes,
   ||RefCounted
 OS|Mac OS X|All

--

[Issue 15754] New: can access alias from instance but not from type

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15754

  Issue ID: 15754
   Summary: can access alias from instance but not from type
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

struct Capture(alias v)
{
alias a = v;
}

void main()
{
int a = 3;
foo(Capture!a());
}

void foo(C)(C c)
{
//f3.d(14): Error: function D main is a nested function and cannot be accessed
from f3.foo!(Capture!(a)).foo
//auto a = C.a; 


// OK:
auto a = C().a;
}

For a start, the error message is seriously confusing (main is nested function?
Whut?).

--

[Issue 15753] clear method for AA not work

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15753

yosik...@altalk.com changed:

   What|Removed |Added

 CC||yosik...@altalk.com

--

[Issue 15753] New: clear method for AA not work

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15753

  Issue ID: 15753
   Summary: clear method for AA not work
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: yosik...@altalk.com

"associative array" page of the language reference clearly denotes:
All keys can be removed by using the method clear.
But following code won't compile.
void main() {
string[string] hash = [ "k":"v" ];
hash.clear();
}

main.d(3): Error: no property 'clear' for type 'string[string]'

--

[Issue 14660] std.range.choose() is not CTFE'able

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=14660

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
Hmm I tried to hack it with:

```
alias CT = CommonType!(ElementType!(Unqual!R1), ElementType!(Unqual!R2));

```

It works well for the runtime, but in CTFE one still gets `cast from int* to
int[]* is not supported`.

Using CT[] compiles in CTFE, but returns garbage.

--

[Issue 6400] opDispatch with WithStatement

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=6400

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #6 from John Colvin  ---
It would be very awesome if this was resolved. Both `opDispatch` and `with` are
under-appreciated parts of the language with a lot of potential.

--

[Issue 15285] Range-ified functions for std.string

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15285

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #3 from Jonathan M Davis  ---
Ideally, all of the string functions would at least accept ranges of
characters, even if that's limited to random-access ranges. Otherwise, code
that uses something like byCodeUnit is going to be in trouble, and arguably,
byCodeUnit should generally be favored over using strings as ranges given the
autodecoding issues.

Whether the string functions accept non-character ranges is another matter
entirely, and if we add functions like that, they really shouldn't be in
std.string.

--

[Issue 15285] Range-ified functions for std.string

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15285

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #2 from greenify  ---
@JackStouffer - is there actually interest/use in allowing ranges for these
functions?
[1,2,3].abbrev doesn't make so much sense to me ...

--

[Issue 10777] std.algorithm.multiSort to return a std.range.SortedRange

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=10777

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #5 from greenify  ---
nice idea @bearophile and @SzMK - how about sharing it as a PR?

--

[Issue 12562] std.algorithm.mul

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=12562

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

[Issue 12141] std.algorithm: implement deterministic topN

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=12141

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

[Issue 15520] Phobos Pull Requests Should Have Automatic Coverage Statistics

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15520

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
How about using Travis and uploading the results to coveralls.io?
Should be possible with doveralls

https://github.com/ColdenCullen/doveralls

--

[Issue 6192] std.algorithm.sort performance

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=6192

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

[Issue 12062] std.range.flatten

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=12062

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

[Issue 14478] isInputRange failed to recognize some ranges

2016-03-04 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=14478

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

43 matches

Mail list logo