[Issue 16973] `hashOf` has error-prone signature as `(T, seed)` may be confused with `(ptr, length)`

[via Digitalmars-d-bugs]

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

--- Comment #4 from Denis Shelomovskii  ---
(In reply to safety0ff.bugz from comment #3)
> (In reply to Denis Shelomovskii from comment #1)
> > This issue caused druntime Issue 16974.
> 
> Druntime used to have a function rt.util.hash.hashOf with signature:
> size_t hashOf( const(void)* buf, size_t len, size_t seed )
> 
> Which made up most references to 'hashOf' within druntime (by TypeInfos.)
> 
> I wouldn't be surprised if this bug was due to thinking it's calling
> rt.util.hash.hashOf instead of object.hashOf.
> 
> Mistaking core.internal.hash.hashOf for rt.util.hash.hashOf was responsible
> for a recent regression.

No doubts it's a function call from wrong module. But it doesn't change the
fact that Issue 16974 is caused by this issue.

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

[via Digitalmars-d-bugs]

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

--- Comment #8 from Timothee Cour  ---
readLink != realpath ; see python realpath:
https://docs.python.org/2/library/os.path.html

realpath returns an absolute path, resolving symlinks recursively (among other
details); readLink doesn't necessarily return an absolute path and may return
something that's a symlink (ie not recursive)

--

[Issue 16976] Implicit conversion from ulong to int in foreach_reverse

[via Digitalmars-d-bugs]

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

--- Comment #1 from Sprink  ---
Correction:

inlining the array like that seems to work as the value is known. Using
anything else though it doesn't work.

int[] values = [ 0, 1, 2 ]; // dynamically

foreach_reverse(int i, v ; values)
{
// error
}

--

[Issue 16976] New: Implicit conversion from ulong to int in foreach_reverse

[via Digitalmars-d-bugs]

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

  Issue ID: 16976
   Summary: Implicit conversion from ulong to int in
foreach_reverse
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: trivial
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sprink.nore...@gmail.com

On a 64-bit system where "length" is ulong, a "foreach" statement allows it to
be implicitly converted to an integer if specified. But the same is not allowed
in foreach_reverse.

foreach(int i, v ; [0, 1, 2])
{
// ok
}

foreach_reverse(int i, v ; [0, 1, 2])
{
// error cannot implicitly convert (__r1234.length) of type ulong to int
}

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

[via Digitalmars-d-bugs]

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

--- Comment #7 from Jacob Carlborg  ---
(In reply to Timothee Cour from comment #6)
> no, as doc says, asNormalizedPath "Does not resolve symbolic links."
> realPath would resolve them recursively (just like python realpath)

Yeah, I thought what was what you wanted? There's already readLink [1] to
resolve symbolic links.

[1] http://dlang.org/phobos/std_file.html#.readLink

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

[via Digitalmars-d-bugs]

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

--- Comment #6 from Timothee Cour  ---
no, as doc says, asNormalizedPath "Does not resolve symbolic links."
realPath would resolve them recursively (just like python realpath)

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

[via Digitalmars-d-bugs]

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

--- Comment #5 from Jacob Carlborg  ---
(In reply to Timothee Cour from comment #4)
> Good point, I just opened a question to figure out if we can even do that:
> 
> http://stackoverflow.com/questions/41190968/how-to-get-path-to-currently-
> running-executable-without-resolving-symlinks-on
> 
> still though, we should have a cross-platform function that implements
> `realPath` (that  one should be doable); and a function to get
> thisExePathUnresolved (that is maybe not available on all platforms)

I think that is asNormalizedPath [1].

[1] http://dlang.org/phobos/std_path.html#asNormalizedPath

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

[via Digitalmars-d-bugs]

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

--- Comment #4 from Timothee Cour  ---
Good point, I just opened a question to figure out if we can even do that:

http://stackoverflow.com/questions/41190968/how-to-get-path-to-currently-running-executable-without-resolving-symlinks-on

still though, we should have a cross-platform function that implements
`realPath` (that  one should be doable); and a function to get
thisExePathUnresolved (that is maybe not available on all platforms)

--

[Issue 16974] [REG2.068] Equal associative arrays with associative array keys are considered unequal

[via Digitalmars-d-bugs]

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

safety0ff.bugz  changed:

   What|Removed |Added

Summary|Equal associative arrays|[REG2.068] Equal
   |with associative array keys |associative arrays with
   |are considered unequal  |associative array keys are
   ||considered unequal

--- Comment #5 from safety0ff.bugz  ---
(In reply to Denis Shelomovskii from comment #3)
> 
> Because at least before 79bc91b41334c1805f557ef2f1606de31c6764d1 [1]
> `rt.util.hash.hashOf` was used in `_aaGetHash`. Though I didn't actually
> test it.

Ah, yea, I see the import was removed, good enough for me.

--

[Issue 16588] uniq's BidirectionalRange behavior is inconsistent with its InputRange behavior

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||pull
 Status|NEW |ASSIGNED

--- Comment #1 from Eduard Staniloiu  ---
https://github.com/dlang/phobos/pull/4961

--

[Issue 8573] A simpler Phobos function that returns the index of the mix or max item

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/d2c7d3761b73405ee39da3fd7fe5030dee35a39e
Issue 8573 - A simpler Phobos function that returns the index of the mix or max
item

Issue 8573 - A simpler Phobos function that returns the index of the mix or max
item

added some review fixes

fixed an issue with a mutable variable

Applied review feedback

Renamed functions to minIndex and maxIndex + used sizediff_t for return value
type

Updated function so that it works optimally even for lazy ranges and algorithms

Reverted to having only copyable elements in ranges

Added more unittests; implemented an array path; fixed documentation

Squashed commits

https://github.com/dlang/phobos/commit/f3a840144a156fce5efee82ca13152c2ac1ef1c3
Merge pull request #4921 from RazvanN7/Issue_8573

Issue 8573 - A simpler Phobos function that returns the index of the …

--

[Issue 16763] Associative array literal inside array or AA literal doesn't work as initializer if variable type is known

[via Digitalmars-d-bugs]

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

--- Comment #1 from Denis Shelomovskii  ---
(In reply to Denis Shelomovskii from comment #0)
> int[int][] b = [[0 : 2]]; // expression ([[1]]) of type int[][]

It was "expression ([[2]])" actually.

So, looks like if `ArrayInitializer.inferType` isn't called AA literals are
treated as array literals with explicit indices (see Static Initialization of
Statically Allocated Arrays [1]) like in this code:
---
import std.stdio;

void main()
{
int[][] a = [[2: 6, 1: 345, 3: 78, 6: 12]];
writeln(a);
int[][] aa = [1: [5: 7], 0: [7], 0: [0: 15] /* overrides previous element
0*/, [2: 6, 1: 3], /* overrides previous element 1*/ ]; 
writeln(aa);
}
---
[[0, 345, 6, 78, 0, 0, 12]]
[[15], [0, 3, 6]]
---


[1] http://dlang.org/spec/arrays.html#static-init-static

--

[Issue 16970] Fix deprecations and warnings when compiling Phobos

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||pull
 Status|NEW |ASSIGNED

--- Comment #2 from Eduard Staniloiu  ---
https://github.com/dlang/phobos/pull/4956

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

[via Digitalmars-d-bugs]

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

--- Comment #3 from Jacob Carlborg  ---
(In reply to Timothee Cour from comment #2)
> at very least it should be documented; but IMO thisExePath has no business
> resolving symlinks; 

If I recall correctly, there was no suitable function in Phobos, at the time of
the implementation, that cleaned up the path so I resorted to "realpath". As a
side effect it also resolves symbolic links. Actually, I don't remember if my
intention was to resolve symbolic links or not.

> and the function that does realpath/readlink should be
> exposed as a separate function (cross platform), so user could call
> realPath(thisExePath) if he wants to.

What about platform consistency? Should the function always return
"/proc/self/exe" on Linux forcing the user to always call "readlink". Or should
they have different behavior?

--

[Issue 16974] Equal associative arrays with associative array keys are considered unequal

[via Digitalmars-d-bugs]

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

--- Comment #4 from Denis Shelomovskii  ---
(In reply to Denis Shelomovskii from comment #3)
> Though I didn't actually

My friend's code which worked around 2.5 years ago is now broken.

--

[Issue 16974] Equal associative arrays with associative array keys are considered unequal

[via Digitalmars-d-bugs]

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

--- Comment #3 from Denis Shelomovskii  ---
(In reply to safety0ff.bugz from comment #2)
> You've marked this as a regression, which version did this previously work
> in?

Because at least before 79bc91b41334c1805f557ef2f1606de31c6764d1 [1]
`rt.util.hash.hashOf` was used in `_aaGetHash`. Though I didn't actually test
it.

[1]
https://github.com/dlang/druntime/commit/79bc91b41334c1805f557ef2f1606de31c6764d1

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

[via Digitalmars-d-bugs]

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #2 from Timothee Cour  ---
at very least it should be documented; but IMO thisExePath has no business
resolving symlinks; and the function that does realpath/readlink should be
exposed as a separate function (cross platform), so user could call
realPath(thisExePath) if he wants to.

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

[via Digitalmars-d-bugs]

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

Jacob Carlborg  changed:

   What|Removed |Added

 CC||d...@me.com

--- Comment #1 from Jacob Carlborg  ---
The implementation of "thisExePath" on macOS calls "realpath". The intention is
to get the full path without any extra "/", "." or "..". Removing the call to
"realpath" from "thisExePath" resolves in the following behavior:

$ ./d/main
/Users/jacob/development/./d/main

The Linux implementation is using "readlink" to read "/proc/self/exe". This
resolves symbolic links as well. I don't know any other way to do it on Linux.
So the behavior of macOS and Linux is at least consistent. I don't remember the
behavior of the other platforms when it comes to symbolic links.

The workaround would be to implement "thisExePath" yourself. That is,
copy-paste the implementation of the existing "thisExePath" and remove the call
to "realpath". Perhaps add a call to "asNormalizedPath" if you want to remove
any extra "/", "." and ".."

--