GHC 2016-12-02

7 comments.

, https://git.io/v1KUv in Homebrew/homebrew-core
By the way, this awkwardly named `5.2-test-1` really is a prerelease of 5.3. See announcement at http://www.zsh.org/mla/users/2016/msg00985.html.

, https://git.io/v1KtA in Homebrew/homebrew-core
zsh 5.2-test-1 (devel)
======================

- [x] Have you followed the [guidelines for contributing](https://github.com/Homebrew/homebrew-core/blob/master/CONTRIBUTING.md)?
- [x] Have you checked that there aren't other open [pull requests](https://github.com/Homebrew/homebrew-core/pulls) for the same formula update/change?
- [x] Have you built your formula locally with `brew install --build-from-source <formula>`, where `<formula>` is the name of the formula you're submitting?
- [x] Does your build pass `brew audit --strict <formula>` (after doing `brew install <formula>`)?

-----

Add option --with-unicode9 on devel and head for Unicode 9 character
width support. The option is not enabled by default because support is
required from both the shell and the terminal emulator; disparity could
cause garbled output. A simple test case is "echo 👍1👍2👍3" at the
prompt:

- If neither zsh nor the terminal emulator has Unicode 9 width tables,
  each digit will overlap with its previous emoji, but editing will still be
  very much possible;

- If zsh has Unicode 9 width tables but the terminal emulator doesn't,
  the string will be garbled and editing will be very difficult;

- If both zsh and the terminal emulator have Unicode 9 width tables,
  output will be correct and editing won't be hindered.

Terminal.app currently doesn't support Unicode 9, making the option a
tough sell as default. For the record, iTerm2 nightlies since 08/08/2016
have opt-in Unicode 9 width support and version switching. See
https://gitlab.com/gnachman/iterm2/wikis/unicodeversionswitching.

---

What's new:

> Changes from 5.2 to 5.3
>
> It is possible to enable character width support for Unicode 9 by
> configuring with `--enable-unicode9'; this compiles in some additional
> tables.  At some point this support may move into a module, in which
> case the configure option will be changed to cause the module to be
> permanently loaded.  This option is not useful unless your terminal also
> supports Unicode 9.
>
> The new word modifier ':P' computes the physical path of the argument.
> It is different from the existing ':a' modifier which always resolves
> '/before/here/../after' to '/before/after', and differs from the
> existing ':A' modifier which resolves symlinks only after 'here/..' is
> removed, even when /before/here is itself a symbolic link.  It is
> recommended to review uses of ':A' and, if appropriate, convert them
> to ':P' as soon as compatibility with 5.2 is no longer a requirement.
>
> The output of "typeset -p" uses "export" commands or the "-g" option
> for parameters that are not local to the current scope.  Previously,
> all output was in the form of "typeset" commands, never using "-g".

, https://git.io/v1KUf in Homebrew/homebrew-core
@paulproteus There's already #5773, blocked due to the test failure. We can probably ship that if `make check` can be removed.

, https://git.io/v1KUJ in Homebrew/homebrew-core
@paulproteus, member of sandstorm-io (parent org of capnp), [claims](https://github.com/Homebrew/homebrew-core/issues/5435#issuecomment-264576618) that it's not essential to pass all tests (if I understood him correctly). Guess we can yank out `make check`.

, https://git.io/v1KUU in Homebrew/homebrew-core
> > Wait for official patch (which should be applied on top of 2.6-alpha3).
>
> I assume that was a joke.

Well it's not... Upstream developer has asked about my opinion, and

> I have advised upstream developer to either use a version test, or use a custom clock_gettime wrapper or replacement with a different name.

I assume he's gonna do something soon...

, https://git.io/v1KUT in Homebrew/homebrew-core
clock_gettime issue is known (although 2.6-alpha2 failure on 10.11 was unknown to me previously), I have advised upstream developer to either use a version test, or use a custom clock_gettime wrapper or replacement with a different name.

Several options for this PR:

1. Since the breakage isn't introduced in this PR (devel spec isn't touched), just admit that devel is broken on 10.11, and merge the stable;

2. I can easily put together an unofficial patch;

3. Wait for official patch (which should be applied on top of 2.6-alpha3).

, https://git.io/v1KUk in Homebrew/homebrew-core
Anyone bothers to requeue this?