[Issue 14995] std.mmfile incorrectly handles errors in ctor

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14995

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

   What|Removed |Added

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

--

[Issue 14868] MmFile destructor seems to corrupt memory

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14868

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

   What|Removed |Added

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

--

[Issue 14994] std.mmfile incorrectly handles map failure

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14994

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

https://github.com/D-Programming-Language/phobos/commit/836be856fa244b253ad8cc12d87668cf9202b295
fix Issue 14994 - std.mmfile incorrectly handles map failure

--

[Issue 14868] MmFile destructor seems to corrupt memory

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14868

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

https://github.com/D-Programming-Language/phobos/commit/1fc0fa1fa9c9e76a77af63114c7e781651a2d4de
fix Issue 14868 - MmFile destructor seems to corrupt memory

--

[Issue 14994] std.mmfile incorrectly handles map failure

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14994

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

   What|Removed |Added

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

--

[Issue 15071] filenames and module names with case-insensitive HFS+

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15071

--- Comment #5 from Sobirari Muhomori  ---
So whether it works or not depends on how you invoke the compiler and not on
the file name.

--

[Issue 6004] std.range.unzip()

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=6004

--- Comment #3 from bearophile_h...@eml.cc ---
(In reply to weaselcat from comment #1)
> I was looking for this in std.range and didn't find anything, came across
> this issue.
> 
> Since this is about 4 years old, was anything like this ever implemented?

There are plenty of old ERs in bugzilla.

--

[Issue 11252] "in" operator for std.range.iota

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=11252

--- Comment #4 from bearophile_h...@eml.cc ---
(In reply to Jonathan M Davis from comment #3)

> Honestly though, this seems like an abuse of the in
> operator to me. in is really intended for lookup in containers. It's
> definitely not a range operation.

There's a very nice "in" operator in D, that most other languages miss, and
it's quite under-used, mostly for irrational reasons.


> in must be no worse than O(log n) or it is inappropriate to use it. And
> given how iota works, that can't possibly be done in anything better than
> O(n) in the general case, though it would be possible to implement it for
> integers specifically. 

I agree. One solution is to not compile the "in" if the search is slower than
O(log n), but it doesn't sound very nice.


> A better alternative would be to add find/canFind as a member function to iota

Using "in" for ranges like iota is more natural (here "natural" means that it
requires the programmer to remember less things) than using find/canFind, but
they seem acceptable.

--

[Issue 12752] std.algorithm.isPermutation

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=12752

--- Comment #3 from bearophile_h...@eml.cc ---
(In reply to github-bugzilla from comment #2)
> Commits pushed to master at https://github.com/D-Programming-Language/phobos

Lot of work for one algorithm.

The range returned by assumePermutationOf(x, y) is sometimes usueful.

--

[Issue 10407] std.conv.to of lazy range to numbers array

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=10407

bearophile_h...@eml.cc changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #2 from bearophile_h...@eml.cc ---
(In reply to hsteoh from comment #1)
> Is this a real bug?

No, it's an enhancement request...


> Couldn't you just do `s.map!(a => a.to!real).array` to do what you want?

Yes, but I think converting lazy ranges is a basic and common need, so it
should be supported by "to".

--

[Issue 15060] Can't load a D shared library first, then load a C shared library

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15060

--- Comment #3 from ponce  ---
Hacky workaround found by bitwise and Martin Nowak:
http://forum.dlang.org/post/lldikuutgrpmmyuhf...@forum.dlang.org

--

[Issue 15085] std.datetime unittest fail due to missing TZname

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15085

Steven Schveighoffer  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|issues.dl...@jmdavisprog.co
   ||m

--

[Issue 15071] filenames and module names with case-insensitive HFS+

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15071

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #6 from ag0ae...@gmail.com ---
(In reply to John Colvin from comment #2)
> I don't expect it to work, but I do expect it to fail with a clear error
> message before link-time.

Do you have a suggestion on how that should be realized?

Module chirplet asks for module mathutil, so the compiler gets it. Then a
different module mathUtil is compiled as is requested on the command line.
Module mathutil has never been compiled and is missing when linking.

I see one way to catch this earlier: dmd could require lower-case file names
and/or module names. But I'm not sure if this issue is worth the disruption
that would cause. Personally, I wouldn't mind it, though.

--

[Issue 15086] New: import doesn't verify module declaration

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15086

  Issue ID: 15086
   Summary: import doesn't verify module declaration
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: accepts-invalid
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

foo.d:

import bar;
pragma(msg, bar.name);


bar.d:

module baz; /* not bar */
enum name = __MODULE__;


`dmd -c foo.d` prints "baz". It should fail with "Error: module baz from file
bar.d must be imported with 'import baz;'" as happens with `dmd -c foo.d
bar.d`.

--

[Issue 15087] DDoc: Add function attributes section for templates

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15087

Jakob Ovrum  changed:

   What|Removed |Added

 CC||jakobov...@gmail.com

--- Comment #1 from Jakob Ovrum  ---
(In reply to Jack Stouffer from comment #0)
> Currently, as function templates are auto attributed, there is no way to
> know if a template is nothrow, pure, @nogc, or @safe without trying to run
> it in your code and seeing if it will compile. That sucks and is tedious.
> 
> So what this bug report is proposing is to add a new section in ddoc headers
> that allows maintainers of phobos to very visually show what attributes the
> template will have with what arguments.
> 
> Sure, sometimes the documentation will say that if the template is @nogc or
> not, but not all the time.
> 
> Also, this answers a common question new comers have, which is "doesn't the
> std lib use the GC?" To which the response is "Not all of it". To which the
> follow up is "Ok, what parts use it and what parts don't?", followed by
> crickets.

DDoc section can be added arbitrarily with any name, there are no restrictions
on them, except a few of them get special handling like `Params`.

Does the proposed section need any special handling? If not, this isn't a DMD
issue.

--

[Issue 15087] DDoc: Add function attributes section for templates

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15087

Jack Stouffer  changed:

   What|Removed |Added

   Keywords||ddoc

--

[Issue 15087] New: DDoc: Add function attributes section for templates

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15087

  Issue ID: 15087
   Summary: DDoc: Add function attributes section for templates
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

Currently, as function templates are auto attributed, there is no way to know
if a template is nothrow, pure, @nogc, or @safe without trying to run it in
your code and seeing if it will compile. That sucks and is tedious.

So what this bug report is proposing is to add a new section in ddoc headers
that allows maintainers of phobos to very visually show what attributes the
template will have with what arguments.

Sure, sometimes the documentation will say that if the template is @nogc or
not, but not all the time.

Also, this answers a common question new comers have, which is "doesn't the std
lib use the GC?" To which the response is "Not all of it". To which the follow
up is "Ok, what parts use it and what parts don't?", followed by crickets.

--

[Issue 15083] New: declaring a variable, cannot access frame pointer

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15083

  Issue ID: 15083
   Summary: declaring a variable, cannot access frame pointer
   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

This uses phobos, but I'm pretty sure typeof should work here so it's a dmd
bug.

import std.file;

void file_test(string path, string filetype, string term){
typeof(dirEntries(path, filetype, SpanMode.depth)) files;
}

Error: cannot access frame pointer of std.file.dirEntries.FilterResult!(f,
DirIterator).FilterResult

--

[Issue 14263] Missing sections core.sys.windows.dll & std.c.windows.windows in runtime documentation

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14263

--- Comment #2 from Anton Pastukhov  ---
It seems that std.c is completely missing in http://dlang.org/phobos

--

[Issue 14263] Missing sections core.sys.windows.dll & std.c.windows.windows in runtime documentation

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14263

Anton Pastukhov  changed:

   What|Removed |Added

 CC||pastuho...@gmail.com

--- Comment #1 from Anton Pastukhov  ---
It seems that std.c is completely missing in http://dlang.org/phobos

--

[Issue 14263] Missing sections core.sys.windows.dll & std.c.windows.windows in runtime documentation

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14263

--- Comment #3 from Anton Pastukhov  ---
oops, doubleposting

--

[Issue 14263] Missing sections core.sys.windows.dll & std.c.windows.windows in runtime documentation

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14263

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com

--- Comment #4 from Dmitry Olshansky  ---
> It seems that std.c is completely missing in http://dlang.org/phobos

Rightly so - use core.stdc.*

--

[Issue 15084] New: GC must ensure there is at least X% of free space in the heap after collection to avoid frequent collections

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15084

  Issue ID: 15084
   Summary: GC must ensure there is at least X% of free space in
the heap after collection to avoid frequent
collections
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: dmitry.o...@gmail.com

One thing that any remotely production-quality GC does is analyze the result of
collection with respect to minimal headroom - X % (typically 30-50%). If we
freed Y % of heap where Y < X, then the GC should extend the heap so that it
get within X % mark of free space in the extended heap. 

See the exchange in NG discussion at
http://forum.dlang.org/thread/mailman.149.1442256696.22025.digitalmar...@puremagic.com

On 14-Sep-2015 21:47, H. S. Teoh via Digitalmars-d wrote:
> Over in the d.learn forum, somebody posted a question about poor
> performance in a text-parsing program. After a bit of profiling I
> discovered that reducing GC collection frequency (i.e., GC.disable()
> then manually call GC.collect() at some interval) improved program
> performance by about 20%.
>
...
On Monday, 14 September 2015 at 18:58:45 UTC, Adam D. Ruppe wrote: 
> Definitely. I think it hits a case where it is right at the edge of the line 
> and you are allocating a small amount.
>
> So it is like the limit is 1,000 bytes. You are at 980 and ask it to allocate 
> 30. So it runs a collection cycle, frees the 30 from the previous loop 
> iteration, then allocates it again... so the whole loop, it is on the edge 
> and runs very often.
>
> Of course, it has to scan everything to ensure it is safe to free those 30 
> bytes so the GC then runs way out of proportion.
>
> Maybe we can make the GC detect this somehow and bump up the size. I don't 
> actually know the implementation that well though.

--

[Issue 15083] declaring a variable, cannot access frame pointer

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15083

--- Comment #2 from John Colvin  ---
(In reply to Marc Schütz from comment #1)
> (In reply to John Colvin from comment #0)
> > This uses phobos, but I'm pretty sure typeof should work here so it's a dmd
> > bug.
> 
> typeof itself _does_ work, this compiles fine:
> 
> pragma(msg, typeof(dirEntries(path, filetype, SpanMode.depth)));
> // prints: FilterResult!(f, DirIterator)

good point

> But FilteResult is evidently a Voldemort type, and you can't declare a
> variable of this type. So I believe this is not a bug.

You can definitely declare variables with Voldemort types.

e.g.
auto foo(){ struct S{} return S(); }
void bar(){ typeof(foo()) a; }

is fine.


The problem here is to do with the initialiser.

typeof(dirEntries(path, filetype, SpanMode.depth)) files = void;

doesn't cause any problems.

--

[Issue 15083] declaring a variable, cannot access frame pointer

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15083

Marc Schütz  changed:

   What|Removed |Added

 CC||schue...@gmx.net

--- Comment #1 from Marc Schütz  ---
(In reply to John Colvin from comment #0)
> This uses phobos, but I'm pretty sure typeof should work here so it's a dmd
> bug.

typeof itself _does_ work, this compiles fine:

pragma(msg, typeof(dirEntries(path, filetype, SpanMode.depth)));
// prints: FilterResult!(f, DirIterator)

But FilteResult is evidently a Voldemort type, and you can't declare a variable
of this type. So I believe this is not a bug.

--

[Issue 14817] [REG-master] copy("foo", "bar") std.algorithm/std.file conflict

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14817

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

   What|Removed |Added

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

--

[Issue 14817] [REG-master] copy("foo", "bar") std.algorithm/std.file conflict

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14817

--- Comment #4 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/1e7246b20128efc94dd7525bdbb58e8ee171ca5e
Fix Issue 14817 - std.algorithm.copy/std.file.copy conflict

https://github.com/D-Programming-Language/phobos/pull/2799 introduced a
regression, which prevented module that imported both std.algorithm and
std.file to use unqualified calls to copy(string, string). The regression was
caused by the removal of template constraints, which were preventing the
std.algorithm copy from being considered for overload resolution.

std.algorithm.copy has two paths: an path for array copies, and a path for all
other copies. Previously they were forked using static if inside function. Now
the decision is made using template constraints.

https://github.com/D-Programming-Language/phobos/commit/f9a6e0b0dd249b8c36820920ae848a3966699352
Add test for issue 14817

https://github.com/D-Programming-Language/phobos/commit/edc405cacd1a60c3e09236bc8b2cca39b271e6b3
Merge pull request #3649 from DmitryOlshansky/poita--issue14817

[REG master] Issue14817 std.algorithm.copy/std.file.copy conflict

--

[Issue 9558] 0b and 0x prefixes for std.string.isNumeric

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=9558

bearophile_h...@eml.cc changed:

   What|Removed |Added

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

--- Comment #2 from bearophile_h...@eml.cc ---
(In reply to hsteoh from comment #1)
> I'm not sure about this. The '0x', '0b', etc., prefixes are syntax defined
> by programming languages, whereas isNumeric is intended to check user input.
> Presumably, most users wouldn't know what 0x, 0b, etc., are, and may be
> surprised to learn that what they consider as invalid input (e.g. 0b10) is
> actually accepted by the program, with results that are unexpected to them.
> 
> Parsing programming language literals should not be conflated with parsing
> user input.

OK, I close this down.

--

[Issue 14995] std.mmfile incorrectly handles errors in ctor

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14995

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

https://github.com/D-Programming-Language/phobos/commit/290a94243f80585f6b42d022c2584fba51035c05
fix Issue 14995 - std.mmfile incorrectly handles errors in ctor

--

[Issue 9065] Please consider adding these std.traits

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=9065

Rory  changed:

   What|Removed |Added

 CC||rjmcgu...@gmail.com

--- Comment #52 from Rory  ---
(In reply to Manu from comment #11)

> template isEnum( T )
> {
>   enum isEnum = is( T == enum );
> }
> 
> // test if something is a variable; has a value, has an address
> template isVariable( alias T )
> {
>   enum isVariable = !is( T ) && is( typeof( T ) ) // if it is not a type, 
> and
> does have a type, it starts to look like a variable
>   && !isFunction!T
> // reject function definitions, they can't be
> assigned to
>   && !isEnum!T
> // reject enum's
>   && !is( typeof( T ) == void );  // 
> reject modules, which appear as a
> variable of type 'void'
> }


Thanks for this, I used this in Adam's jsvar to get a more meaningful
conversion from enum to bool which was initially causing the module to not be
valid because isIntegral!(some enum) == true.

--

[Issue 15083] declaring a variable, cannot access frame pointer

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15083

--- Comment #4 from John Colvin  ---
(In reply to Marc Schütz from comment #3)
> (In reply to John Colvin from comment #2)
> > You can definitely declare variables with Voldemort types.
> > 
> > e.g.
> > auto foo(){ struct S{} return S(); }
> > void bar(){ typeof(foo()) a; }
> > 
> > is fine.
> > 
> 
> That's not a "real" Voldemort type with a closure; try this instead:
> 
> auto foo(){
> int x;
> struct S {
> int baz() { return x; }
> }
> return S();
> }
> void bar(){ typeof(foo()) a; } // Error: cannot access frame pointer of
> xx.foo.S

OK, I see what you mean.

> > 
> > The problem here is to do with the initialiser.
> > 
> > typeof(dirEntries(path, filetype, SpanMode.depth)) files = void;
> > 
> > doesn't cause any problems.
> 
> This could either be an oversight (= bug), or it could be intentional. I
> suspect the latter, because it allows to actually declare a Voldemort
> variable that is only initialized later.

Yes, I think it probably is intentional, or at least not a problem that it's
allowed.

--

[Issue 15083] declaring a variable, cannot access frame pointer

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15083

--- Comment #3 from Marc Schütz  ---
(In reply to John Colvin from comment #2)
> You can definitely declare variables with Voldemort types.
> 
> e.g.
> auto foo(){ struct S{} return S(); }
> void bar(){ typeof(foo()) a; }
> 
> is fine.
> 

That's not a "real" Voldemort type with a closure; try this instead:

auto foo(){
int x;
struct S {
int baz() { return x; }
}
return S();
}
void bar(){ typeof(foo()) a; } // Error: cannot access frame pointer of
xx.foo.S

> 
> The problem here is to do with the initialiser.
> 
>   typeof(dirEntries(path, filetype, SpanMode.depth)) files = void;
> 
> doesn't cause any problems.

This could either be an oversight (= bug), or it could be intentional. I
suspect the latter, because it allows to actually declare a Voldemort variable
that is only initialized later.

--

[Issue 15085] New: std.datetime unittest fail due to missing TZname

2015-09-18 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15085

  Issue ID: 15085
   Summary: std.datetime unittest fail due to missing TZname
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: r.sagita...@gmx.de

The phobos unittests suddenly fail on Windows (8.1) with

core.exception.AssertError@std\datetime.d(26918): TZName which is missing:
Eastern Standard Time (Mexico)

I guess there has been some update from Microsoft that changed the timezone
data base, probably https://support.microsoft.com/en-us/kb/3049874

--