Stream: GitHub notifications

Topic: Coq Noisy Notifications


view this post on Zulip Coq Github Bot (May 18 2020 at 14:05):

a891dd5 changed its status to pending.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:21):

60ec5b9 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:25):

60ec5b9 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:25):

60ec5b9 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:32):

a891dd5 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:33):

a891dd5 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:33):

a891dd5 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:41):

ejgallego labeled Issue #7390 [doc] Moving away from LaTeX (assigned to ejgallego):

After the completion of the Sphinx migration [#6818], there are only residual TeX files in the tree; we all tend to agree that they would rather be moved to other formats. In today's master we can see the remaining files:

egallego@rochefort$ find . -name *.tex
./vernac/doc.tex
./interp/doc.tex
./lib/doc.tex
./pretyping/doc.tex
./proofs/doc.tex
./library/doc.tex
./tactics/doc.tex
./kernel/doc.tex

I will take care of removing these once #7155 lands, I will move the corresponding text there to the proper files. We are waiting on a new odoc upstream release for that tho + Dune.

./dev/v8-syntax/syntax-v8.tex
./dev/v8-syntax/memo-v8.tex
./dev/ocamldoc/header.tex
./dev/doc/naming-conventions.tex
./dev/doc/versions-history.tex
./dev/doc/newsyntax.tex
./dev/doc/minicoq.tex

No idea on what to do with these files? Should be converted to MarkDown / RST ?

./doc/tools/Translator.tex
./doc/common/title.tex
./doc/common/version.tex
./doc/common/macros.tex
./doc/stdlib/Library.coqdoc.tex
./doc/stdlib/Library.tex
./doc/tutorial/Tutorial.tex
./doc/tutorial/Tutorial.v.tex
./doc/whodidwhat/whodidwhat-8.5update.tex
./doc/whodidwhat/whodidwhat-8.2update.tex
./doc/whodidwhat/whodidwhat-8.4update.tex
./doc/whodidwhat/whodidwhat-8.3update.tex
./doc/RecTutorial/recmacros.tex
./doc/RecTutorial/RecTutorial.tex
./doc/RecTutorial/coqartmacros.tex

I guess a few of these files should be ported to Sphinx; dunno for the rest.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:55):

4d82233 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:57):

b456cf6 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:57):

ejgallego merged PR #11980 Improve spacing in Print Assumptions.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:57):

a891dd5 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:57):

ejgallego updated PR #12346 Update to 8.13. (assigned to ejgallego) from bump-8.13 to master:

Part of this PR was automatically generated by running dev/doc/update-compat.py --master.

Kind: infrastructure.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:58):

f123874 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 14:58):

ejgallego merged PR #12346 Update to 8.13.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:02):

ea6cb6b changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:09):

Zimmi48 commented on f123874:

@gares This is the commit to tag (with git tag -s V8.13+alpha && git push upstream V8.13+alpha).

view this post on Zulip Coq Github Bot (May 18 2020 at 15:10):

Zimmi48 demilestoned Issue #12246 Adding support for applying in several hypotheses at the same time (granting #9816)

Kind: enhancement

This is a first attempt at granting wish #9816: applying apply in to several hypotheses at the same time, either under the form apply c in H1, H2 or apply c in *. See request for comments at #9816.

Closes #9816.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:10):

Zimmi48 milestoned Issue #12246 Adding support for applying in several hypotheses at the same time (granting #9816)

Kind: enhancement

This is a first attempt at granting wish #9816: applying apply in to several hypotheses at the same time, either under the form apply c in H1, H2 or apply c in *. See request for comments at #9816.

Closes #9816.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:10):

Zimmi48 demilestoned Issue #12316 Use pagination in fetching the number of reviews:

Fixes #12300

Note that I currently only paginate the API call for the number of
reviews, not the main API call, because (a) the main API call doesn't
seem subject to pagination (it returns a dict, not an array), and (b)
because fetching the total number of pages incurs an extra API call for
each one that we want to paginate, even if there is only one page. We
could work around (b) with a significantly more complicated
curl_paginate function which heuristically recognizes the end of the
header/beginning of the body, such as

curl_paginate() {
  # as per https://developer.github.com/v3/guides/traversing-with-pagination/#changing-the-number-of-items-received, GitHub will never give us more than 100
  url="$1?per_page=100"
  # We need to process the header to get the pagination.  We have two
  # options:
  #
  # 1. We can make an extra API call at the beginning to get the total
  #    number of pages, search for a rel="last" link, and then loop
  #    over all the pages.
  #
  # 2. We can ask for the header info with every single curl request,
  #    search for a rel="next" link to follow to the next page, and
  #    then parse out the body from the header.
  #
  # Although (1) is simpler, we choose to do (2) to save an extra API
  # call per invocation of curl.
  while [ ! -z "${url}" ]; do
    response="$(curl -si "${url}")"
    # we search for something like 'link: <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="next", <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="last"' and take the first 'next' url
    url="$(echo "${response}" | grep -m 1 -io '^link: .*>; rel="next"' | grep -o '<[^>]*>; rel="next"' | grep -o '<[^>]*>' | sed s'/[<>]//g')"
    echo "Response: ${response}" >&2
    echo "${response}" |
      {
        is_header="yes"
        while read line; do
          if [ "${is_header}" == "yes" ]; then
            if echo "${line}" | grep -q '^\s*[\[{]'; then # we treat lines beginning with [ or { as the beginning of the response body
              is_header="no"
              echo "${line}"
            fi
          else
            echo "${line}"
          fi
        done
      }
  done
}

Kind: bug fix / infrastructure.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:10):

Zimmi48 milestoned Issue #12316 Use pagination in fetching the number of reviews:

Fixes #12300

Note that I currently only paginate the API call for the number of
reviews, not the main API call, because (a) the main API call doesn't
seem subject to pagination (it returns a dict, not an array), and (b)
because fetching the total number of pages incurs an extra API call for
each one that we want to paginate, even if there is only one page. We
could work around (b) with a significantly more complicated
curl_paginate function which heuristically recognizes the end of the
header/beginning of the body, such as

curl_paginate() {
  # as per https://developer.github.com/v3/guides/traversing-with-pagination/#changing-the-number-of-items-received, GitHub will never give us more than 100
  url="$1?per_page=100"
  # We need to process the header to get the pagination.  We have two
  # options:
  #
  # 1. We can make an extra API call at the beginning to get the total
  #    number of pages, search for a rel="last" link, and then loop
  #    over all the pages.
  #
  # 2. We can ask for the header info with every single curl request,
  #    search for a rel="next" link to follow to the next page, and
  #    then parse out the body from the header.
  #
  # Although (1) is simpler, we choose to do (2) to save an extra API
  # call per invocation of curl.
  while [ ! -z "${url}" ]; do
    response="$(curl -si "${url}")"
    # we search for something like 'link: <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="next", <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="last"' and take the first 'next' url
    url="$(echo "${response}" | grep -m 1 -io '^link: .*>; rel="next"' | grep -o '<[^>]*>; rel="next"' | grep -o '<[^>]*>' | sed s'/[<>]//g')"
    echo "Response: ${response}" >&2
    echo "${response}" |
      {
        is_header="yes"
        while read line; do
          if [ "${is_header}" == "yes" ]; then
            if echo "${line}" | grep -q '^\s*[\[{]'; then # we treat lines beginning with [ or { as the beginning of the response body
              is_header="no"
              echo "${line}"
            fi
          else
            echo "${line}"
          fi
        done
      }
  done
}

Kind: bug fix / infrastructure.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:12):

Zimmi48 created branch v8.12.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:12):

b456cf6 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:20):

b456cf6 changed its status to pending.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:20):

ea6cb6b changed its status to pending.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:21):

b456cf6 changed its status to pending.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:22):

JasonGross edited PR #12316 Use pagination in fetching the number of reviews from fix-12300 to master:

Fixes #12300

Note that I currently only paginate the API call for the number of
reviews, not the main API call, because (a) the main API call doesn't
seem subject to pagination (it returns a dict, not an array), and (b)
because fetching the total number of pages incurs an extra API call for
each one that we want to paginate, even if there is only one page. We
could work around (b) with a significantly more complicated
curl_paginate function which heuristically recognizes the end of the
header/beginning of the body, such as

curl_paginate() {
  # as per https://developer.github.com/v3/guides/traversing-with-pagination/#changing-the-number-of-items-received, GitHub will never give us more than 100
  url="$1?per_page=100"
  # We need to process the header to get the pagination.  We have two
  # options:
  #
  # 1. We can make an extra API call at the beginning to get the total
  #    number of pages, search for a rel="last" link, and then loop
  #    over all the pages.
  #
  # 2. We can ask for the header info with every single curl request,
  #    search for a rel="next" link to follow to the next page, and
  #    then parse out the body from the header.
  #
  # Although (1) is simpler, we choose to do (2) to save an extra API
  # call per invocation of curl.
  while [ ! -z "${url}" ]; do
    response="$(curl -si "${url}")"
    # we search for something like 'link: <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="next", <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="last"' and take the first 'next' url
    url="$(echo "${response}" | grep -m 1 -io '^link: .*>; rel="next"' | grep -o '<[^>]*>; rel="next"' | grep -o '<[^>]*>' | sed s'/[<>]//g')"
    echo "${response}" |
      {
        is_header="yes"
        while read line; do
          if [ "${is_header}" == "yes" ]; then
            if echo "${line}" | grep -q '^\s*[\[{]'; then # we treat lines beginning with [ or { as the beginning of the response body
              is_header="no"
              echo "${line}"
            fi
          else
            echo "${line}"
          fi
        done
      }
  done
}

Kind: bug fix / infrastructure.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:23):

ejgallego commented on f123874:

We should also propose a standard tag message for the git tag command.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:25):

Zimmi48 edited Issue #11157 Release 8.12 (assigned to Zimmi48):

Release process

As soon as 8.11 has branched off master and 8.12 RM have been nominated do:

About one month before the beta

On the date of the feature freeze

Before the beta release date

These steps are the same for all releases (beta, final, patch-level)

At the final release time

Repeat the generic process documented above for all releases.

At the patch-level release time

We generally do not update the magic numbers at this point (see
2881a18).

Compatibility Infrastructure Update

Additionally, in the same commit, update the compatibility
infrastructure, which consists of invoking
dev/tools/update-compat.py with the
--master flag.

Note that the update-compat.py script must be run twice: once
immediately after branching with the --master flag (which sets
up Coq to support four -compat flag arguments), *in the same
commit* as the one that updates coq_version in
configure.ml, and once again later on before
the next branch point with the --release flag (see next section).

view this post on Zulip Coq Github Bot (May 18 2020 at 15:25):

Zimmi48 edited Issue #11157 Release 8.12 (assigned to Zimmi48):

Release process

As soon as 8.11 has branched off master and 8.12 RM have been nominated do:

About one month before the beta

On the date of the feature freeze

Before the beta release date

These steps are the same for all releases (beta, final, patch-level)

At the final release time

Repeat the generic process documented above for all releases.

At the patch-level release time

We generally do not update the magic numbers at this point (see
2881a18).

Compatibility Infrastructure Update

Additionally, in the same commit, update the compatibility
infrastructure, which consists of invoking
dev/tools/update-compat.py with the
--master flag.

Note that the update-compat.py script must be run twice: once
immediately after branching with the --master flag (which sets
up Coq to support four -compat flag arguments), *in the same
commit* as the one that updates coq_version in
configure.ml, and once again later on before
the next branch point with the --release flag (see next section).

view this post on Zulip Coq Github Bot (May 18 2020 at 15:25):

Zimmi48 edited Issue #11157 Release 8.12 (assigned to Zimmi48):

Release process

As soon as 8.11 has branched off master and 8.12 RM have been nominated do:

About one month before the beta

On the date of the feature freeze

Before the beta release date

These steps are the same for all releases (beta, final, patch-level)

At the final release time

Repeat the generic process documented above for all releases.

At the patch-level release time

We generally do not update the magic numbers at this point (see
2881a18).

Compatibility Infrastructure Update

Additionally, in the same commit, update the compatibility
infrastructure, which consists of invoking
dev/tools/update-compat.py with the
--master flag.

Note that the update-compat.py script must be run twice: once
immediately after branching with the --master flag (which sets
up Coq to support four -compat flag arguments), *in the same
commit* as the one that updates coq_version in
configure.ml, and once again later on before
the next branch point with the --release flag (see next section).

view this post on Zulip Coq Github Bot (May 18 2020 at 15:26):

ejgallego assigned Issue #12264 Errors when running test suite with recent Dune. (assigned to ejgallego):

Description of the problem

When dune runtest, [build errors appear][log]. Some of them can be solved by [a few chmod invocations][patch]. [Other errors are then reached][log2] for which I have not found a solution. Test suite therefore fails.

[log]: https://gist.github.com/kindaro/d284b4e8bcc76aaefaba192ad2f3f371#file-dune-log
[patch]: https://gist.github.com/kindaro/d284b4e8bcc76aaefaba192ad2f3f371#file-fix-diff
[log2]: https://gist.github.com/kindaro/d284b4e8bcc76aaefaba192ad2f3f371#file-dune-2-log

My suspicion is that [the upgrade of _dune_][dune] has something to do with this.

[dune]: https://github.com/coq/coq/commit/bc411fa4d8c04424c579d506dd0507cb83db7bc7

Software versions

Coq Version

The Coq Proof Assistant, version 8.12+alpha (May 2020)
compiled on May 6 2020 4:32:32 with OCaml 4.09.0

Dune Version

2.5.0
2.5.1

Make Version

GNU Make 4.3
Built for x86_64-pc-linux-gnu

CSDP Version

Name            : coin-or-csdp
Version         : 6.2.0-3
Description     : A C library for Semidefinite Programming
Architecture    : x86_64

_(On Arch Linux.)_

view this post on Zulip Coq Github Bot (May 18 2020 at 15:26):

ejgallego milestoned Issue #12264 Errors when running test suite with recent Dune. (assigned to ejgallego):

Description of the problem

When dune runtest, [build errors appear][log]. Some of them can be solved by [a few chmod invocations][patch]. [Other errors are then reached][log2] for which I have not found a solution. Test suite therefore fails.

[log]: https://gist.github.com/kindaro/d284b4e8bcc76aaefaba192ad2f3f371#file-dune-log
[patch]: https://gist.github.com/kindaro/d284b4e8bcc76aaefaba192ad2f3f371#file-fix-diff
[log2]: https://gist.github.com/kindaro/d284b4e8bcc76aaefaba192ad2f3f371#file-dune-2-log

My suspicion is that [the upgrade of _dune_][dune] has something to do with this.

[dune]: https://github.com/coq/coq/commit/bc411fa4d8c04424c579d506dd0507cb83db7bc7

Software versions

Coq Version

The Coq Proof Assistant, version 8.12+alpha (May 2020)
compiled on May 6 2020 4:32:32 with OCaml 4.09.0

Dune Version

2.5.0
2.5.1

Make Version

GNU Make 4.3
Built for x86_64-pc-linux-gnu

CSDP Version

Name            : coin-or-csdp
Version         : 6.2.0-3
Description     : A C library for Semidefinite Programming
Architecture    : x86_64

_(On Arch Linux.)_

view this post on Zulip Coq Github Bot (May 18 2020 at 15:37):

3decaca changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:38):

b456cf6 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:44):

ea6cb6b changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:44):

ea6cb6b changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:47):

b456cf6 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:47):

b456cf6 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:47):

b456cf6 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:48):

ea6cb6b changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:48):

ea6cb6b changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:48):

ea6cb6b changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:50):

gares edited Issue #12334 Release 8.13 (assigned to maximedenes):

Release process

As soon as the previous version branched off master

In principle, these steps should be undertaken by the RM of the next
release. Unfortunately, we have not yet been able to nominate RMs
early enough in the process for this person to be known at that point
in time.

Anytime after the previous version is branched off master

About one month before the beta

On the date of the feature freeze

Before the beta release date

These steps are the same for all releases (beta, final, patch-level)

At the final release time

Repeat the generic process documented above for all releases.

Ping @Zimmi48 to:

At the patch-level release time

We generally do not update the magic numbers at this point (see
2881a18).

view this post on Zulip Coq Github Bot (May 18 2020 at 15:51):

b456cf6 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:51):

b456cf6 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:51):

gares edited Issue #12334 Release 8.13 (assigned to maximedenes):

Release process

As soon as the previous version branched off master

In principle, these steps should be undertaken by the RM of the next
release. Unfortunately, we have not yet been able to nominate RMs
early enough in the process for this person to be known at that point
in time.

Anytime after the previous version is branched off master

About one month before the beta

On the date of the feature freeze

Before the beta release date

These steps are the same for all releases (beta, final, patch-level)

At the final release time

Repeat the generic process documented above for all releases.

Ping @Zimmi48 to:

At the patch-level release time

We generally do not update the magic numbers at this point (see
2881a18).

view this post on Zulip Coq Github Bot (May 18 2020 at 15:55):

ejgallego milestoned Issue #12350 [test-suite] Ensure copies of files are writable:

This is needed for the case the sources are set to read-only mode, for
example when using Dune >= 2.5 [needed for the global cache support]

Fixes #12264

Co-authored-by: Ignat Insarov <kindaro@gmail.com>

view this post on Zulip Coq Github Bot (May 18 2020 at 15:55):

ejgallego opened PR #12350 [test-suite] Ensure copies of files are writable from test-suite+fix_dune_read_only to master:

This is needed for the case the sources are set to read-only mode, for
example when using Dune >= 2.5 [needed for the global cache support]

Fixes #12264

Co-authored-by: Ignat Insarov <kindaro@gmail.com>

view this post on Zulip Coq Github Bot (May 18 2020 at 15:55):

ejgallego requested test-suite-maintainers and coq-makefile-maintainers for a review on PR #12350 [test-suite] Ensure copies of files are writable.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:55):

ejgallego requested test-suite-maintainers and coq-makefile-maintainers for a review on PR #12350 [test-suite] Ensure copies of files are writable.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:55):

17de81c changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:56):

gares created tag V8.13+alpha.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:56):

gares edited Issue #12334 Release 8.13 (assigned to maximedenes):

Release process

As soon as the previous version branched off master

In principle, these steps should be undertaken by the RM of the next
release. Unfortunately, we have not yet been able to nominate RMs
early enough in the process for this person to be known at that point
in time.

Anytime after the previous version is branched off master

About one month before the beta

On the date of the feature freeze

Before the beta release date

These steps are the same for all releases (beta, final, patch-level)

At the final release time

Repeat the generic process documented above for all releases.

Ping @Zimmi48 to:

At the patch-level release time

We generally do not update the magic numbers at this point (see
2881a18).

view this post on Zulip Coq Github Bot (May 18 2020 at 15:57):

ea6cb6b changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:58):

17de81c changed its status to pending.

view this post on Zulip Coq Github Bot (May 18 2020 at 15:58):

92e21cb changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:02):

f123874 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:04):

JasonGross updated PR #12316 Use pagination in fetching the number of reviews from fix-12300 to master:

Fixes #12300

Note that I currently only paginate the API call for the number of
reviews, not the main API call, because (a) the main API call doesn't
seem subject to pagination (it returns a dict, not an array), and (b)
because fetching the total number of pages incurs an extra API call for
each one that we want to paginate, even if there is only one page. We
could work around (b) with a significantly more complicated
curl_paginate function which heuristically recognizes the end of the
header/beginning of the body, such as

curl_paginate() {
  # as per https://developer.github.com/v3/guides/traversing-with-pagination/#changing-the-number-of-items-received, GitHub will never give us more than 100
  url="$1?per_page=100"
  # We need to process the header to get the pagination.  We have two
  # options:
  #
  # 1. We can make an extra API call at the beginning to get the total
  #    number of pages, search for a rel="last" link, and then loop
  #    over all the pages.
  #
  # 2. We can ask for the header info with every single curl request,
  #    search for a rel="next" link to follow to the next page, and
  #    then parse out the body from the header.
  #
  # Although (1) is simpler, we choose to do (2) to save an extra API
  # call per invocation of curl.
  while [ ! -z "${url}" ]; do
    response="$(curl -si "${url}")"
    # we search for something like 'link: <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="next", <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="last"' and take the first 'next' url
    url="$(echo "${response}" | grep -m 1 -io '^link: .*>; rel="next"' | grep -o '<[^>]*>; rel="next"' | grep -o '<[^>]*>' | sed s'/[<>]//g')"
    echo "${response}" |
      {
        is_header="yes"
        while read line; do
          if [ "${is_header}" == "yes" ]; then
            if echo "${line}" | grep -q '^\s*[\[{]'; then # we treat lines beginning with [ or { as the beginning of the response body
              is_header="no"
              echo "${line}"
            fi
          else
            echo "${line}"
          fi
        done
      }
  done
}

Kind: bug fix / infrastructure.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:04):

674df18 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:09):

JasonGross opened Issue #12351 Redirect ignores Set Printing Width:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Axiom foo : forall a b c d e f g h i j k l m n o p q r s t u v w x y z : Set, a->b->c->d->e->f->g->h->i->j->k->l->m->n->o->p->q->r->s->t->u->v->w->x->y->z.
Set Printing Width 10000.
Print Assumptions foo.
(* Axioms:
foo : forall a b c d e f g h i j k l m n o p q r s t u v w x y z : Set, a -> b -> c -> d -> e -> f -> g -> h -> i -> j -> k -> l -> m -> n -> o -> p -> q -> r -> s -> \
t -> u -> v -> w -> x -> y -> z *)
Redirect "foo" Print Assumptions foo.
(* Axioms:
foo : forall a b c d e f g h i j k l m n o p q r s t u v w x y z : Set,
      a ->
      b ->
      c ->
      d ->
      e ->
      f ->
      g ->
      h ->
      i ->
      j ->
      k ->
      l -> m -> n -> o -> p -> q -> r -> s -> t -> u -> v -> w -> x -> y -> z
*)

This makes it much more annoying to make fiat-crypto compatible with #11980 in a backwards-compatible way.

Coq Version

8.11.1

view this post on Zulip Coq Github Bot (May 18 2020 at 16:11):

JasonGross opened Issue #12352 #11980 had no changelog entry (assigned to SkySkimmer).

view this post on Zulip Coq Github Bot (May 18 2020 at 16:11):

JasonGross assigned Issue #12352 #11980 had no changelog entry (assigned to SkySkimmer).

view this post on Zulip Coq Github Bot (May 18 2020 at 16:11):

JasonGross milestoned Issue #12352 #11980 had no changelog entry (assigned to SkySkimmer).

view this post on Zulip Coq Github Bot (May 18 2020 at 16:11):

SkySkimmer unassigned Issue #12352 #11980 had no changelog entry (assigned to SkySkimmer).

view this post on Zulip Coq Github Bot (May 18 2020 at 16:15):

herbelin merged PR #12289 test-suite: fix bug causing unit tests to be skipped.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:16):

2222e45 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:18):

gares requested contributing-process-maintainers for a review on PR #12353 Update release-process.md.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:18):

gares opened PR #12353 Update release-process.md from gares-patch-1 to master:

About the commit that should be tagged VXX+alpha

view this post on Zulip Coq Github Bot (May 18 2020 at 16:18):

e1e4073 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:24):

Zimmi48 milestoned Issue #12353 Update release-process.md:

About the commit that should be tagged VXX+alpha

view this post on Zulip Coq Github Bot (May 18 2020 at 16:25):

17de81c changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:26):

17de81c changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:27):

ejgallego assigned PR #12353 Update release-process.md to ejgallego.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:28):

2222e45 changed its status to pending.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:30):

17de81c changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:30):

17de81c changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:33):

gares updated PR #12353 Update release-process.md (assigned to ejgallego) from gares-patch-1 to master:

About the commit that should be tagged VXX+alpha

view this post on Zulip Coq Github Bot (May 18 2020 at 16:33):

ffe1de0 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:40):

Zimmi48 demilestoned Issue #12352 #11980 had no changelog entry.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:40):

Zimmi48 closed Issue #12352 #11980 had no changelog entry.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:40):

Zimmi48 labeled Issue #12352 #11980 had no changelog entry.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:43):

ejgallego opened PR #12354 [universes] [api] Provide UState.from_env from proofs+better_uctx_constructor to master:

This seems like a recurring pattern, and IMO makes a bit better API.

We also remove merge_universe_subst as it is not needed so far, as
we were creating stale evar_maps just for this purpose.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:43):

e3dc950 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:44):

e3dc950 changed its status to pending.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:45):

2222e45 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:51):

2222e45 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:53):

b7c14a8 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:56):

SkySkimmer assigned PR #12354 [universes] [api] Provide UState.from_env to SkySkimmer.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:57):

Zimmi48 updated PR #12224 Support :gdef:text<term> syntax (adding "<term>") (assigned to cpitclaudel) from gdef_alias to master:

Permits displaying the plural or capitalized form of the term while indexing the unmodified term.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:57):

2222e45 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:57):

2222e45 changed its status to success.

view this post on Zulip Coq Github Bot (May 18 2020 at 16:57):

c92de18 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:00):

c92de18 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:02):

c92de18 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:02):

c92de18 changed its status to error.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:03):

c92de18 changed its status to pending.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:04):

c92de18 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:04):

c92de18 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:07):

Zimmi48 assigned PR #12316 Use pagination in fetching the number of reviews.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:08):

e3dc950 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:09):

e3dc950 changed its status to failure.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:14):

Zimmi48 updated PR #12224 Support :gdef:text<term> syntax (adding "<term>") (assigned to cpitclaudel) from gdef_alias to master:

Permits displaying the plural or capitalized form of the term while indexing the unmodified term.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:27):

Zimmi48 opened PR #12355 Use pinned commits in dev/ci/ci-user-overlays.sh. (assigned to ejgallego) from pin-overlays to v8.12:

Kind: infrastructure.

While preparing this PR (by running dev/tools/pin-overlays), I have discovered that our referenced URL to coq-menhirlib (only used in the Windows build AFAIR) does not exist anymore. This likely means that the full Windows is currently failing. It looks like coq-menhirlib is now developed at https://gitlab.inria.fr/fpottier/menhir/-/tree/master/coq-menhirlib.

cc @MSoegtropIMC

view this post on Zulip Coq Github Bot (May 18 2020 at 17:27):

Zimmi48 milestoned Issue #12355 Use pinned commits in dev/ci/ci-user-overlays.sh. (assigned to ejgallego):

Kind: infrastructure.

While preparing this PR (by running dev/tools/pin-overlays), I have discovered that our referenced URL to coq-menhirlib (only used in the Windows build AFAIR) does not exist anymore. This likely means that the full Windows is currently failing. It looks like coq-menhirlib is now developed at https://gitlab.inria.fr/fpottier/menhir/-/tree/master/coq-menhirlib.

cc @MSoegtropIMC

view this post on Zulip Coq Github Bot (May 18 2020 at 17:27):

Zimmi48 assigned [PR #12355 Use pinned commits in dev/ci/ci-user-overlays.sh.](https://github.com/coq/coq/pull/12355 to ejgallego.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:27):

Zimmi48 requested ci-maintainers for a review on PR #12355 Use pinned commits in dev/ci/ci-user-overlays.sh..

view this post on Zulip Coq Github Bot (May 18 2020 at 17:29):

SkySkimmer edited PR #12355 [8.12] Use pinned commits in dev/ci/ci-user-overlays.sh. (assigned to ejgallego) from pin-overlays to v8.12:

Kind: infrastructure.

While preparing this PR (by running dev/tools/pin-overlays), I have discovered that our referenced URL to coq-menhirlib (only used in the Windows build AFAIR) does not exist anymore. This likely means that the full Windows is currently failing. It looks like coq-menhirlib is now developed at https://gitlab.inria.fr/fpottier/menhir/-/tree/master/coq-menhirlib.

cc @MSoegtropIMC

view this post on Zulip Coq Github Bot (May 18 2020 at 17:29):

ejgallego opened PR #12356 [declare] Remove unused parameters in prepare_obligation from declare+nit to master:

Cleanup PR.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:29):

Zimmi48 updated PR #12224 Support :gdef:text<term> syntax (adding "<term>") (assigned to cpitclaudel) from gdef_alias to master:

Permits displaying the plural or capitalized form of the term while indexing the unmodified term.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:33):

ejgallego updated PR #12301 [declare] Grand unification of the proof save path. (assigned to SkySkimmer) from proof+fuse_3 to master:

We complete some arduous refactoring in order to bring all the
internals and code of constant / proof saving into the same module.

In particular, this PR moves the remaining parts of proof saving from
Lemmas to Declare.

The reduction in exposed internals is considerable; in particular, we
remove the export of the internals of proof_entry and proof_object
[used in delayed proofs], which will allow us to start to address many
issues with the current setup, such as #10363 .

There are still some TODOs, that will be addressed in subsequent PRs:

List of remaining offenders for proof_entry / declare_constant in
the codebase:

@ppedrot @SkySkimmer I know it is quite late but IMO it'd be great to try to get this merged in 8.12. The PR itself is straightforward, and there are no overlays.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:38):

Janno updated PR #12349 Allow dependent products in canonical instances. from janno/cs_dep_prod to master:

This removes the restriction to non-dependent products. Dependent and non-dependent products are handled the same way.

The code is arguably simpler than before and also more powerful. I have some use cases in mind but they would probably only work with Unicoq so I can't provide a very compelling example here. In any case, @gares and @mattam82 seemed to agree that this could be a worthwhile change, and, based on what @ggonthier's wrote in https://github.com/coq/coq/issues/11189#issuecomment-558673619, it seems that removing the dependency check could be the right thing to do even without any use cases where the function type actually is dependent (as opposed to just appearing dependent during unification).

This needs benchmarking since it might well be slower for non-dependent functions than the original code.

I'll add documentation after #12329 is merged since that PR contains new documentation for canonical structures.

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: feature.

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 18 2020 at 17:41):

Zimmi48 updated PR #12224 Support :gdef:text<term> syntax (adding "<term>") (assigned to cpitclaudel) from gdef_alias to master:

Permits displaying the plural or capitalized form of the term while indexing the unmodified term.

view this post on Zulip Coq Github Bot (May 18 2020 at 17:56):

ejgallego opened PR #12357 [declare] Remove some unused fix_exn from proof+no_fix_exn to master:

In the current proof save path, the kernel can raise an exception when
checking a proof wrapped into a future.

However, in this case, the future itself will "fix" the produced
exception, with the mandatory handler set at the future's creation
time.

Thus, there is no need for the declare layer to mess with exceptions
anymore, if my logic is correct. Note that the fix_exn parameter to
the Declare API was not used anymore.

This undoes 77cf18eb844b45776b2ec67be9f71e8dd4ca002c which comes from
pre-github times, so unfortunately I didn't have access to the
discussion.

This needs some manual testing.

view this post on Zulip Coq Github Bot (May 18 2020 at 19:56):

Zimmi48 updated PR #12224 Support :gdef:text<term> syntax (adding "<term>") (assigned to cpitclaudel) from gdef_alias to master:

Permits displaying the plural or capitalized form of the term while indexing the unmodified term.

view this post on Zulip Coq Github Bot (May 18 2020 at 20:15):

ejgallego opened PR #12358 [topfmt] Set formatter + flush fix from redirect_printing_params to master:

Closes #12351.

We set the parameters of the redirect formatter to be same than the
ones in stdout.

I guess the original semantics was to ignore the parameters, so I'm
unsure we want to do this.

While we are a it, we include a fix on the formatter, which _must_ be
flushed before closing its associated channel.

view this post on Zulip Coq Github Bot (May 18 2020 at 20:15):

ejgallego requested vernac-maintainers for a review on PR #12358 [topfmt] Set formatter + flush fix.

view this post on Zulip Coq Github Bot (May 18 2020 at 20:16):

ejgallego updated PR #12358 [topfmt] Set formatter + flush fix from redirect_printing_params to master:

Closes #12351.

We set the parameters of the redirect formatter to be same than the
ones in stdout.

I guess the original semantics was to ignore the parameters, so I'm
unsure we want to do this.

While we are a it, we include a fix on the formatter, which _must_ be
flushed before closing its associated channel.

view this post on Zulip Coq Github Bot (May 18 2020 at 20:16):

ejgallego milestoned Issue #12358 [topfmt] Set formatter + flush fix:

Closes #12351.

We set the parameters of the redirect formatter to be same than the
ones in stdout.

I guess the original semantics was to ignore the parameters, so I'm
unsure we want to do this.

While we are a it, we include a fix on the formatter, which _must_ be
flushed before closing its associated channel.

view this post on Zulip Coq Github Bot (May 18 2020 at 20:16):

ejgallego requested JasonGross and vernac-maintainers for a review on PR #12358 [topfmt] Set formatter + flush fix.

view this post on Zulip Coq Github Bot (May 18 2020 at 21:40):

ppedrot assigned PR #11986 [primitive floats] Add low level printing to ppedrot.

view this post on Zulip Coq Github Bot (May 19 2020 at 00:35):

jfehrle updated PR #12224 Support :gdef:text<term> syntax (adding "<term>") (assigned to cpitclaudel) from gdef_alias to master:

Permits displaying the plural or capitalized form of the term while indexing the unmodified term.

view this post on Zulip Coq Github Bot (May 19 2020 at 02:01):

JasonGross opened PR #12359 [ci] Add mit-plv/engine-bench from add-engine-bench to master:

This is a new development where I'm aggregating a specific set of
benchmarks. It's intended to be relatively lightweight, taking only a
handful of minutes (I can make the CI target much, much lighter if
desired). It's probably one of the few developments currently testing
Ltac2.

Kind: infrastructure

view this post on Zulip Coq Github Bot (May 19 2020 at 02:01):

JasonGross requested ci-maintainers for a review on PR #12359 [ci] Add mit-plv/engine-bench.

view this post on Zulip Coq Github Bot (May 19 2020 at 02:16):

JasonGross updated PR #12359 [ci] Add mit-plv/engine-bench from add-engine-bench to master:

This is a new development where I'm aggregating a specific set of
benchmarks. It's intended to be relatively lightweight, taking only a
handful of minutes (I can make the CI target much, much lighter if
desired). It's probably one of the few developments currently testing
Ltac2.

Kind: infrastructure

view this post on Zulip Coq Github Bot (May 19 2020 at 02:18):

jfehrle updated PR #12224 Support :gdef:text<term> syntax (adding "<term>") (assigned to cpitclaudel) from gdef_alias to master:

Permits displaying the plural or capitalized form of the term while indexing the unmodified term.

view this post on Zulip Coq Github Bot (May 19 2020 at 02:39):

jfehrle updated PR #12224 Support :gdef:text<term> syntax (adding "<term>") (assigned to cpitclaudel) from gdef_alias to master:

Permits displaying the plural or capitalized form of the term while indexing the unmodified term.

view this post on Zulip Coq Github Bot (May 19 2020 at 07:04):

MSoegtropIMC updated PR #12186 CReal: changed epsilon for modulus of convergence from 1/n to 1/2^n from creal-new-modulus to master:

This PR changes the epsilon in the definition of the modulus of convergence for CReal from 1/n to 1/2^n. This avoids the issue that in practical high precision computations, even as binary integer n would be quite large (say 2^1000000), although quadratically convergent algorithms might need only a few 10 iterations to reach such a precision.

This is work in progress (right now I just did the main file ConstructiveCauchyReals.v).

@VincentSe : some things I think I should change:

view this post on Zulip Coq Github Bot (May 19 2020 at 07:36):

proux01 updated PR #11986 [primitive floats] Add low level printing (assigned to ppedrot) from float-low-level-printing to master:

Add flag Printing Float to print primitive floats as hexadecimal
instead of decimal values. This is included in Set Printing All.

This follows prior discussions in #11859 and #11611

~Depends on : #11948~

view this post on Zulip Coq Github Bot (May 19 2020 at 07:45):

fajb updated PR #11906 [micromega] native support for boolean operators from bmicromega to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

Kind: feature
(this is a clean revival of #11047 )

view this post on Zulip Coq Github Bot (May 19 2020 at 08:51):

ppedrot milestoned Issue #11986 [primitive floats] Add low level printing (assigned to ppedrot):

Add flag Printing Float to print primitive floats as hexadecimal
instead of decimal values. This is included in Set Printing All.

This follows prior discussions in #11859 and #11611

~Depends on : #11948~

view this post on Zulip Coq Github Bot (May 19 2020 at 09:51):

fajb updated PR #11906 [micromega] native support for boolean operators from bmicromega to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

Kind: feature
(this is a clean revival of #11047 )

view this post on Zulip Coq Github Bot (May 19 2020 at 10:00):

SkySkimmer updated PR #11604 Primitive persistent arrays from persistent-arrays to master:

TODO:

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 19 2020 at 10:07):

proux01 updated PR #11986 [primitive floats] Add low level printing (assigned to ppedrot) from float-low-level-printing to master:

Add flag Printing Float to print primitive floats as hexadecimal
instead of decimal values. This is included in Set Printing All.

This follows prior discussions in #11859 and #11611

~Depends on : #11948~

view this post on Zulip Coq Github Bot (May 19 2020 at 12:12):

SkySkimmer merged PR #12301 [declare] Grand unification of the proof save path.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:15):

SkySkimmer assigned PR #12350 [test-suite] Ensure copies of files are writable to SkySkimmer.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:23):

ejgallego merged PR #12353 Update release-process.md.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:31):

ejgallego updated PR #12354 [universes] [api] Provide UState.from_env (assigned to SkySkimmer) from proofs+better_uctx_constructor to master:

This seems like a recurring pattern, and IMO makes a bit better API.

We also remove merge_universe_subst as it is not needed so far, as
we were creating stale evar_maps just for this purpose.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:32):

ejgallego updated PR #12357 [declare] Remove some unused fix_exn from proof+no_fix_exn to master:

In the current proof save path, the kernel can raise an exception when
checking a proof wrapped into a future.

However, in this case, the future itself will "fix" the produced
exception, with the mandatory handler set at the future's creation
time.

Thus, there is no need for the declare layer to mess with exceptions
anymore, if my logic is correct. Note that the fix_exn parameter to
the Declare API was not used anymore.

This undoes 77cf18eb844b45776b2ec67be9f71e8dd4ca002c which comes from
pre-github times, so unfortunately I didn't have access to the
discussion.

This needs some manual testing.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:32):

ejgallego requested lib-maintainers, stm-maintainers and vernac-maintainers for a review on PR #12357 [declare] Remove some unused fix_exn.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:32):

ejgallego requested lib-maintainers, stm-maintainers and vernac-maintainers for a review on PR #12357 [declare] Remove some unused fix_exn.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:32):

ejgallego requested lib-maintainers, stm-maintainers and vernac-maintainers for a review on PR #12357 [declare] Remove some unused fix_exn.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:32):

ejgallego updated PR #12356 [declare] Remove unused parameters in prepare_obligation from declare+nit to master:

Cleanup PR.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:33):

ejgallego requested vernac-maintainers for a review on PR #12356 [declare] Remove unused parameters in prepare_obligation.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:33):

ejgallego requested engine-maintainers, universes-maintainers and vernac-maintainers for a review on PR #12354 [universes] [api] Provide UState.from_env.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:33):

ejgallego requested engine-maintainers, universes-maintainers and vernac-maintainers for a review on PR #12354 [universes] [api] Provide UState.from_env.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:33):

ejgallego requested engine-maintainers, universes-maintainers and vernac-maintainers for a review on PR #12354 [universes] [api] Provide UState.from_env.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:34):

ejgallego updated PR #11836 [obligations] Functionalize Program state from obligations+functional to master:

In our quest to unify all the declaration paths, an important step
is to account for the state pertaining to Program declarations.

Whereas regular proofs keep are kept in a stack-like structure;
obligations for constants defined by Program are stored in a global
map which is manipulated by almost regular open/close proof primitives.

We make this manipulation explicit by handling the program state
functionally, in a similar way than we already do for lemmas.

This requires to extend the proof DSL a bit; but IMO changes are
acceptable given the gain.

Most of the PR is routine; only remarkable change is that the hook is
called explicitly in finish_admitted as it had to learn about the
different types of proof_endings.

Note that we could have gone deeper and use the type system to refine
the core proof type; IMO it is still too preliminary so it is better
to do this step as an intermediate one towards a deeper unification.

Depends on the rest of proof state work, c.f. #11818

After this PR we are ready to reduce DeclareObl to a minimal file; likely unifying the two declaration paths.

Overlays:

view this post on Zulip Coq Github Bot (May 19 2020 at 12:36):

SkySkimmer submitted PR Review for #12354 [universes] [api] Provide UState.from_env.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:41):

SkySkimmer submitted PR Review for #12356 [declare] Remove unused parameters in prepare_obligation.

view this post on Zulip Coq Github Bot (May 19 2020 at 12:41):

SkySkimmer assigned PR #12356 [declare] Remove unused parameters in prepare_obligation to SkySkimmer.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:08):

fajb updated PR #11906 [micromega] native support for boolean operators from bmicromega to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

Kind: feature
(this is a clean revival of #11047 )

view this post on Zulip Coq Github Bot (May 19 2020 at 14:19):

Zimmi48 opened Issue #12360 Carefully select the version to include in the Windows installer. (assigned to Zimmi48):

Before tagging and releasing 8.12+beta1 we need to select more carefully (than #12355) the version of the add-ons that will be in the installer. As often as possible, we should aim for tagged versions (releases), possibly slightly patched for compatibility.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:19):

Zimmi48 assigned Issue #12360 Carefully select the version to include in the Windows installer. (assigned to Zimmi48):

Before tagging and releasing 8.12+beta1 we need to select more carefully (than #12355) the version of the add-ons that will be in the installer. As often as possible, we should aim for tagged versions (releases), possibly slightly patched for compatibility.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:19):

Zimmi48 assigned Issue #12360 Carefully select the version to include in the Windows installer. (assigned to Zimmi48):

Before tagging and releasing 8.12+beta1 we need to select more carefully (than #12355) the version of the add-ons that will be in the installer. As often as possible, we should aim for tagged versions (releases), possibly slightly patched for compatibility.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:19):

Zimmi48 labeled Issue #12360 Carefully select the version to include in the Windows installer. (assigned to Zimmi48):

Before tagging and releasing 8.12+beta1 we need to select more carefully (than #12355) the version of the add-ons that will be in the installer. As often as possible, we should aim for tagged versions (releases), possibly slightly patched for compatibility.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:19):

Zimmi48 labeled Issue #12360 Carefully select the version to include in the Windows installer. (assigned to Zimmi48):

Before tagging and releasing 8.12+beta1 we need to select more carefully (than #12355) the version of the add-ons that will be in the installer. As often as possible, we should aim for tagged versions (releases), possibly slightly patched for compatibility.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:19):

Zimmi48 milestoned Issue #12360 Carefully select the version to include in the Windows installer. (assigned to Zimmi48):

Before tagging and releasing 8.12+beta1 we need to select more carefully (than #12355) the version of the add-ons that will be in the installer. As often as possible, we should aim for tagged versions (releases), possibly slightly patched for compatibility.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:20):

Zimmi48 submitted PR Review for #12355 [8.12] Use pinned commits in dev/ci/ci-user-overlays.sh.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:26):

Zimmi48 edited PR #12355 [8.12] Use pinned commits in dev/ci/ci-user-overlays.sh. (assigned to ejgallego) from pin-overlays to v8.12:

Kind: infrastructure.

While preparing this PR (by running dev/tools/pin-ci.sh), I have discovered that our referenced URL to coq-menhirlib (only used in the Windows build AFAIR) does not exist anymore. This likely means that the full Windows is currently failing. It looks like coq-menhirlib is now developed at https://gitlab.inria.fr/fpottier/menhir/-/tree/master/coq-menhirlib.

cc @MSoegtropIMC

view this post on Zulip Coq Github Bot (May 19 2020 at 14:44):

Zimmi48 opened Issue #12361 Multiple index keys for the same command does not work in the PDF output.

Description of the problem

In the 8.12 version of the reference manual, it is possible to have a single command that is referred to by multiple index keys (this is the case of Definition / Example, Theorem and variants, Parameter and variants, Require / Require Import / Require Export, Implicit Type and plural form, Record / Structure). This works fine in the HTML output, but it doesn't in the PDF output: only the last key works, and the others are displayed with some ?? showing a reference not found.

See example here: https://coq.gitlab.io/-/coq/-/jobs/543104421/artifacts/_install_ci/share/doc/coq/sphinx/latex/CoqRefMan.pdf

Coq Version

v8.12 and master

cc @jfehrle who implemented this feature

view this post on Zulip Coq Github Bot (May 19 2020 at 14:44):

Zimmi48 labeled Issue #12361 Multiple index keys for the same command does not work in the PDF output.

Description of the problem

In the 8.12 version of the reference manual, it is possible to have a single command that is referred to by multiple index keys (this is the case of Definition / Example, Theorem and variants, Parameter and variants, Require / Require Import / Require Export, Implicit Type and plural form, Record / Structure). This works fine in the HTML output, but it doesn't in the PDF output: only the last key works, and the others are displayed with some ?? showing a reference not found.

See example here: https://coq.gitlab.io/-/coq/-/jobs/543104421/artifacts/_install_ci/share/doc/coq/sphinx/latex/CoqRefMan.pdf

Coq Version

v8.12 and master

cc @jfehrle who implemented this feature

view this post on Zulip Coq Github Bot (May 19 2020 at 14:44):

Zimmi48 labeled Issue #12361 Multiple index keys for the same command does not work in the PDF output.

Description of the problem

In the 8.12 version of the reference manual, it is possible to have a single command that is referred to by multiple index keys (this is the case of Definition / Example, Theorem and variants, Parameter and variants, Require / Require Import / Require Export, Implicit Type and plural form, Record / Structure). This works fine in the HTML output, but it doesn't in the PDF output: only the last key works, and the others are displayed with some ?? showing a reference not found.

See example here: https://coq.gitlab.io/-/coq/-/jobs/543104421/artifacts/_install_ci/share/doc/coq/sphinx/latex/CoqRefMan.pdf

Coq Version

v8.12 and master

cc @jfehrle who implemented this feature

view this post on Zulip Coq Github Bot (May 19 2020 at 14:44):

Zimmi48 milestoned Issue #12361 Multiple index keys for the same command does not work in the PDF output.

Description of the problem

In the 8.12 version of the reference manual, it is possible to have a single command that is referred to by multiple index keys (this is the case of Definition / Example, Theorem and variants, Parameter and variants, Require / Require Import / Require Export, Implicit Type and plural form, Record / Structure). This works fine in the HTML output, but it doesn't in the PDF output: only the last key works, and the others are displayed with some ?? showing a reference not found.

See example here: https://coq.gitlab.io/-/coq/-/jobs/543104421/artifacts/_install_ci/share/doc/coq/sphinx/latex/CoqRefMan.pdf

Coq Version

v8.12 and master

cc @jfehrle who implemented this feature

view this post on Zulip Coq Github Bot (May 19 2020 at 14:46):

MSoegtropIMC submitted PR Review for #12355 [8.12] Use pinned commits in dev/ci/ci-user-overlays.sh.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:47):

Zimmi48:

view this post on Zulip Coq Github Bot (May 19 2020 at 14:51):

Zimmi48:

view this post on Zulip Coq Github Bot (May 19 2020 at 14:55):

Zimmi48 edited PR #12295 Fixes #12233: printing environment corrupted with eta-expansion of "match" branches (assigned to ppedrot) from master+fix12234-show-proof to master:

Kind: bug fix

The main fix is in Detyping.decomp_branch which needs a declaration to push to the environment even in the eta-expansion cases.

In the process, we preserve binder annotations in detyping (maybe not so useful, but morally better, for instance for funind).

Note: we left an horrible hack in the case of LetIn expansion. This is supposed to disappear with #9710.

Fixes / closes #12233

view this post on Zulip Coq Github Bot (May 19 2020 at 14:56):

Zimmi48 edited PR Review Comment on #12358 [topfmt] Set formatter + flush fix.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:57):

Zimmi48 submitted PR Review for #12358 [topfmt] Set formatter + flush fix.

view this post on Zulip Coq Github Bot (May 19 2020 at 14:57):

Zimmi48 created PR Review Comment on #12358 [topfmt] Set formatter + flush fix:

@JasonGross I've slightly amended your suggestion because the way to refer to commands is through :cmd:, not :cmdv: (the latter does not exist).

view this post on Zulip Coq Github Bot (May 19 2020 at 15:00):

Zimmi48 updated PR #12342 Direct URL for triggering a pipeline with SKIP_DOCKER=false. (assigned to SkySkimmer) from doc-trigger-pipeline to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: documentation

view this post on Zulip Coq Github Bot (May 19 2020 at 15:02):

Zimmi48 updated PR #12342 Direct URL for triggering a pipeline with SKIP_DOCKER=false. (assigned to SkySkimmer) from doc-trigger-pipeline to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: documentation

view this post on Zulip Coq Github Bot (May 19 2020 at 15:15):

Zimmi48 updated PR #12342 Direct URL for triggering a pipeline with SKIP_DOCKER=false. (assigned to SkySkimmer) from doc-trigger-pipeline to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: documentation

view this post on Zulip Coq Github Bot (May 19 2020 at 15:26):

cpitclaudel submitted PR Review for #12224 Support :gdef:text<term> syntax (adding "<term>")

view this post on Zulip Coq Github Bot (May 19 2020 at 15:27):

cpitclaudel pushed 4 commits to branch master. Commits by Zimmi48 (2), cpitclaudel (1) and jfehrle (1).

view this post on Zulip Coq Github Bot (May 19 2020 at 15:27):

cpitclaudel closed Issue #11936 Coq refman search does not work (assigned to Zimmi48):

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

If you go to https://coq.github.io/doc/master/refman/, search doesn't work. The javascript console says Stemmer is not defined, which lead me to https://github.com/sphinx-doc/sphinx/issues/5460. It's possible the refman needs to be regenerated with a fixed version of Sphinx.

Coq Version

8.12+alpha

view this post on Zulip Coq Github Bot (May 19 2020 at 15:27):

cpitclaudel merged PR #12224 Support :gdef:text<term> syntax (adding "<term>")

view this post on Zulip Coq Github Bot (May 19 2020 at 15:47):

gares milestoned Issue #12349 Allow dependent products in canonical instances.

This removes the restriction to non-dependent products. Dependent and non-dependent products are handled the same way.

The code is arguably simpler than before and also more powerful. I have some use cases in mind but they would probably only work with Unicoq so I can't provide a very compelling example here. In any case, @gares and @mattam82 seemed to agree that this could be a worthwhile change, and, based on what @ggonthier's wrote in https://github.com/coq/coq/issues/11189#issuecomment-558673619, it seems that removing the dependency check could be the right thing to do even without any use cases where the function type actually is dependent (as opposed to just appearing dependent during unification).

This needs benchmarking since it might well be slower for non-dependent functions than the original code.

I'll add documentation after #12329 is merged since that PR contains new documentation for canonical structures.

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: feature.

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 19 2020 at 15:48):

ejgallego updated PR #12357 [declare] Remove some unused fix_exn from proof+no_fix_exn to master:

In the current proof save path, the kernel can raise an exception when
checking a proof wrapped into a future.

However, in this case, the future itself will "fix" the produced
exception, with the mandatory handler set at the future's creation
time.

Thus, there is no need for the declare layer to mess with exceptions
anymore, if my logic is correct. Note that the fix_exn parameter to
the Declare API was not used anymore.

This undoes 77cf18eb844b45776b2ec67be9f71e8dd4ca002c which comes from
pre-github times, so unfortunately I didn't have access to the
discussion.

This needs some manual testing.

view this post on Zulip Coq Github Bot (May 19 2020 at 16:03):

ejgallego submitted PR Review for #12358 [topfmt] Set formatter + flush fix.

view this post on Zulip Coq Github Bot (May 19 2020 at 16:03):

ejgallego created PR Review Comment on #12358 [topfmt] Set formatter + flush fix:

Done thanks.

view this post on Zulip Coq Github Bot (May 19 2020 at 16:26):

Zimmi48 milestoned Issue #12362 Use dev version for opam git pinning in .gitlab-ci.yml.

The main reason for this change is to reduce the number of places where the Coq version is hardcoded.

But moreover, I don't see why that wouldn't work since dev is precisely the version that is defined in the opam files.

view this post on Zulip Coq Github Bot (May 19 2020 at 16:26):

Zimmi48 opened PR #12362 Use dev version for opam git pinning in .gitlab-ci.yml. from gitlab-opam-dev to master:

The main reason for this change is to reduce the number of places where the Coq version is hardcoded.

But moreover, I don't see why that wouldn't work since dev is precisely the version that is defined in the opam files.

view this post on Zulip Coq Github Bot (May 19 2020 at 16:26):

Zimmi48 requested ci-maintainers for a review on PR #12362 Use dev version for opam git pinning in .gitlab-ci.yml..

view this post on Zulip Coq Github Bot (May 19 2020 at 16:31):

Zimmi48 milestoned Issue #12363 Tweak the OCaml version used to generate the MacOS package.

(cherry picked from commit 45432df10d92b090fe3aaa3cc2f99c006fe621a6)

cf. #12310

view this post on Zulip Coq Github Bot (May 19 2020 at 16:31):

Zimmi48 opened PR #12363 Tweak the OCaml version used to generate the MacOS package. from macos-binary-8.12 to v8.12:

(cherry picked from commit 45432df10d92b090fe3aaa3cc2f99c006fe621a6)

cf. #12310

view this post on Zulip Coq Github Bot (May 19 2020 at 16:31):

Zimmi48 requested ci-maintainers for a review on PR #12363 Tweak the OCaml version used to generate the MacOS package..

view this post on Zulip Coq Github Bot (May 19 2020 at 16:36):

ejgallego updated PR #12358 [topfmt] Set formatter + flush fix from redirect_printing_params to master:

Closes #12351.

We set the parameters of the redirect formatter to be same than the
ones in stdout.

I guess the original semantics was to ignore the parameters, so I'm
unsure we want to do this.

While we are a it, we include a fix on the formatter, which _must_ be
flushed before closing its associated channel.

view this post on Zulip Coq Github Bot (May 19 2020 at 16:43):

ejgallego requested erikmd and ci-maintainers for a review on PR #12362 Use dev version for opam git pinning in .gitlab-ci.yml..

view this post on Zulip Coq Github Bot (May 19 2020 at 16:47):

ejgallego opened PR #12364 [ci] [docker] Bump ocamlformat and dune from ci+bump_deps to master:

cc: #12350

view this post on Zulip Coq Github Bot (May 19 2020 at 16:47):

ejgallego requested ci-maintainers for a review on PR #12364 [ci] [docker] Bump ocamlformat and dune.

view this post on Zulip Coq Github Bot (May 19 2020 at 16:57):

ejgallego updated PR #12364 [ci] [docker] Bump ocamlformat and dune from ci+bump_deps to master:

cc: #12350

view this post on Zulip Coq Github Bot (May 19 2020 at 17:02):

gasparattila opened Issue #12365 "exists a, b" can fail even if "exists a; exists b" succeeds:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

<!-- If you can, it's helpful to provide self-contained example of some code
that reproduces the bug. If not, a link to a larger example is also helpful. -->

Parameter a b : nat.
Parameter p : a = b.

Goal exists (_ : True) (_ : exists x, x = b), True.
Proof.
  Fail exists I, (ex_intro _ a p).
  exists I; exists (ex_intro _ a p).

The failure is caused by the evar constraints from ex_intro _ a p being present when I is used. These constraints cannot be solved by unification without additional information from the goal.

Coq Version

8.11.0
<!-- You can get this information by running coqtop -v. If relevant, please
also include your operating system. -->

view this post on Zulip Coq Github Bot (May 19 2020 at 17:05):

SkySkimmer labeled Issue #12365 "exists a, b" can fail even if "exists a; exists b" succeeds:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

<!-- If you can, it's helpful to provide self-contained example of some code
that reproduces the bug. If not, a link to a larger example is also helpful. -->

Parameter a b : nat.
Parameter p : a = b.

Goal exists (_ : True) (_ : exists x, x = b), True.
Proof.
  Fail exists I, (ex_intro _ a p).
  exists I; exists (ex_intro _ a p).

The failure is caused by the evar constraints from ex_intro _ a p being present when I is used. These constraints cannot be solved by unification without additional information from the goal.

Coq Version

8.11.0
<!-- You can get this information by running coqtop -v. If relevant, please
also include your operating system. -->

view this post on Zulip Coq Github Bot (May 19 2020 at 17:06):

ejgallego updated PR #12358 [topfmt] Set formatter + flush fix from redirect_printing_params to master:

Closes #12351.

We set the parameters of the redirect formatter to be same than the
ones in stdout.

I guess the original semantics was to ignore the parameters, so I'm
unsure we want to do this.

While we are a it, we include a fix on the formatter, which _must_ be
flushed before closing its associated channel.

view this post on Zulip Coq Github Bot (May 19 2020 at 17:33):

ejgallego:

view this post on Zulip Coq Github Bot (May 19 2020 at 17:41):

JasonGross submitted PR Review for #12358 [topfmt] Set formatter + flush fix.

view this post on Zulip Coq Github Bot (May 19 2020 at 17:47):

ejgallego updated PR #12358 [topfmt] Set formatter + flush fix from redirect_printing_params to master:

Closes #12351.

We set the parameters of the redirect formatter to be same than the
ones in stdout.

I guess the original semantics was to ignore the parameters, so I'm
unsure we want to do this.

While we are a it, we include a fix on the formatter, which _must_ be
flushed before closing its associated channel.

view this post on Zulip Coq Github Bot (May 19 2020 at 17:59):

gasparattila opened PR #12366 Delay evaluating arguments of the "exists" tactic from fix-exists to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: bug fix

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #12365

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 19 2020 at 17:59):

gasparattila requested ltac-maintainers for a review on PR #12366 Delay evaluating arguments of the "exists" tactic.

view this post on Zulip Coq Github Bot (May 19 2020 at 18:02):

ejgallego assigned [PR #12363 Tweak the OCaml version used to generate the MacOS package.](https://github.com/coq/coq/pull/12363 to ejgallego.

view this post on Zulip Coq Github Bot (May 19 2020 at 18:36):

cpitclaudel labeled Issue #12367 Could we make coq-ltac2 a dummy package in 8.11 instead of requiring Coq < 8.11?

Description of the problem

I'm trying to support 8.9 through 8.11 in the same project. I use Ltac2, so I have a dependency on the coq-ltac2 package. But currently that package requires Coq < 8.11.

Could the coq-ltac2 be marked as compatible with 8.11 and made to install a dummy package there? Or is there a simpler solution that I overlooked?

cc @ppedrot

view this post on Zulip Coq Github Bot (May 19 2020 at 18:36):

cpitclaudel opened Issue #12367 Could we make coq-ltac2 a dummy package in 8.11 instead of requiring Coq < 8.11?

Description of the problem

I'm trying to support 8.9 through 8.11 in the same project. I use Ltac2, so I have a dependency on the coq-ltac2 package. But currently that package requires Coq < 8.11.

Could the coq-ltac2 be marked as compatible with 8.11 and made to install a dummy package there? Or is there a simpler solution that I overlooked?

cc @ppedrot

view this post on Zulip Coq Github Bot (May 19 2020 at 19:18):

JasonGross updated PR #12359 [ci] Add mit-plv/engine-bench from add-engine-bench to master:

This is a new development where I'm aggregating a specific set of
benchmarks. It's intended to be relatively lightweight, taking only a
handful of minutes (I can make the CI target much, much lighter if
desired). It's probably one of the few developments currently testing
Ltac2.

Kind: infrastructure

view this post on Zulip Coq Github Bot (May 19 2020 at 19:19):

fajb requested pi8027, maximedenes, doc-maintainers and stdlib-maintainers for a review on PR #11906 [micromega] native support for boolean operators.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:30):

gasparattila updated PR #12366 Delay evaluating arguments of the "exists" tactic from fix-exists to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: bug fix

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #12365

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 19 2020 at 19:32):

JasonGross updated PR #12316 Use pagination in fetching the number of reviews (assigned to Zimmi48) from fix-12300 to master:

Fixes #12300

Note that I currently only paginate the API call for the number of
reviews, not the main API call, because (a) the main API call doesn't
seem subject to pagination (it returns a dict, not an array), and (b)
because fetching the total number of pages incurs an extra API call for
each one that we want to paginate, even if there is only one page. We
could work around (b) with a significantly more complicated
curl_paginate function which heuristically recognizes the end of the
header/beginning of the body, such as

curl_paginate() {
  # as per https://developer.github.com/v3/guides/traversing-with-pagination/#changing-the-number-of-items-received, GitHub will never give us more than 100
  url="$1?per_page=100"
  # We need to process the header to get the pagination.  We have two
  # options:
  #
  # 1. We can make an extra API call at the beginning to get the total
  #    number of pages, search for a rel="last" link, and then loop
  #    over all the pages.
  #
  # 2. We can ask for the header info with every single curl request,
  #    search for a rel="next" link to follow to the next page, and
  #    then parse out the body from the header.
  #
  # Although (1) is simpler, we choose to do (2) to save an extra API
  # call per invocation of curl.
  while [ ! -z "${url}" ]; do
    response="$(curl -si "${url}")"
    # we search for something like 'link: <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="next", <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="last"' and take the first 'next' url
    url="$(echo "${response}" | grep -m 1 -io '^link: .*>; rel="next"' | grep -o '<[^>]*>; rel="next"' | grep -o '<[^>]*>' | sed s'/[<>]//g')"
    echo "${response}" |
      {
        is_header="yes"
        while read line; do
          if [ "${is_header}" == "yes" ]; then
            if echo "${line}" | grep -q '^\s*[\[{]'; then # we treat lines beginning with [ or { as the beginning of the response body
              is_header="no"
              echo "${line}"
            fi
          else
            echo "${line}"
          fi
        done
      }
  done
}

Kind: bug fix / infrastructure.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:32):

erikmd submitted PR Review for #12362 Use dev version for opam git pinning in .gitlab-ci.yml.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:35):

erikmd submitted PR Review for #12362 Use dev version for opam git pinning in .gitlab-ci.yml.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:44):

SkySkimmer submitted PR Review for #12316 Use pagination in fetching the number of reviews.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:44):

SkySkimmer created PR Review Comment on #12316 Use pagination in fetching the number of reviews:

    if [ "$(jq 'length' <<< "$response")" -lt 100 ]; then # done

skips a fetch most of the time
and no need for {} here while we're at it

view this post on Zulip Coq Github Bot (May 19 2020 at 19:44):

SkySkimmer submitted PR Review for #12316 Use pagination in fetching the number of reviews.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:44):

SkySkimmer created PR Review Comment on #12316 Use pagination in fetching the number of reviews:

    page=$(($page + 1))

some spacing shouldn't hurt

view this post on Zulip Coq Github Bot (May 19 2020 at 19:44):

SkySkimmer created PR Review Comment on #12316 Use pagination in fetching the number of reviews:

  # we keep fetching pages until the response is below the per-page limit (possibly 0 elements)

We don't care about alternatives we don't use here.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:44):

SkySkimmer created PR Review Comment on #12316 Use pagination in fetching the number of reviews:

Not needed AFAICT


view this post on Zulip Coq Github Bot (May 19 2020 at 19:47):

Zimmi48 assigned PR #12316 Use pagination in fetching the number of reviews to SkySkimmer.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:47):

Zimmi48 unassigned PR #12316 Use pagination in fetching the number of reviews to SkySkimmer.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:48):

ejgallego updated PR #12357 [declare] Remove some unused fix_exn from proof+no_fix_exn to master:

In the current proof save path, the kernel can raise an exception when
checking a proof wrapped into a future.

However, in this case, the future itself will "fix" the produced
exception, with the mandatory handler set at the future's creation
time.

Thus, there is no need for the declare layer to mess with exceptions
anymore, if my logic is correct. Note that the fix_exn parameter to
the Declare API was not used anymore.

This undoes 77cf18eb844b45776b2ec67be9f71e8dd4ca002c which comes from
pre-github times, so unfortunately I didn't have access to the
discussion.

This needs some manual testing.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:49):

ejgallego edited PR #12357 [declare] Remove some unused fix_exn from proof+no_fix_exn to master:

In the current proof save path, the kernel can raise an exception when
checking a proof wrapped into a future.

However, in this case, the future itself will "fix" the produced
exception, with the mandatory handler set at the future's creation
time.

Thus, there is no need for the declare layer to mess with exceptions
anymore, if my logic is correct. Note that the fix_exn parameter to
the Declare API was not used anymore.

This undoes 77cf18eb844b45776b2ec67be9f71e8dd4ca002c which comes from
pre-github times, so unfortunately I didn't have access to the
discussion.

We need to be careful in perform_buildp as to catch the Qed error
and properly notify the STM about it with State.exn_on; this was
previously done by the declare layer using a hack [grabbing internal
state of the future, that the future itself was not using as it was
already forced], but we now do it in the caller in a more principled
way.

This has been tested in the case that tactics succeed but Qed fails
asynchronously.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:55):

JasonGross submitted PR Review for #12316 Use pagination in fetching the number of reviews.

view this post on Zulip Coq Github Bot (May 19 2020 at 19:55):

JasonGross created PR Review Comment on #12316 Use pagination in fetching the number of reviews:

This is actually already required in master without being checked for https://github.com/coq/coq/blob/ed0f2f08e31ee4e645aa6e52970ddefc60f1f4f9/dev/tools/merge-pr.sh#L107

view this post on Zulip Coq Github Bot (May 19 2020 at 19:55):

JasonGross updated PR #12316 Use pagination in fetching the number of reviews (assigned to SkySkimmer) from fix-12300 to master:

Fixes #12300

Note that I currently only paginate the API call for the number of
reviews, not the main API call, because (a) the main API call doesn't
seem subject to pagination (it returns a dict, not an array), and (b)
because fetching the total number of pages incurs an extra API call for
each one that we want to paginate, even if there is only one page. We
could work around (b) with a significantly more complicated
curl_paginate function which heuristically recognizes the end of the
header/beginning of the body, such as

curl_paginate() {
  # as per https://developer.github.com/v3/guides/traversing-with-pagination/#changing-the-number-of-items-received, GitHub will never give us more than 100
  url="$1?per_page=100"
  # We need to process the header to get the pagination.  We have two
  # options:
  #
  # 1. We can make an extra API call at the beginning to get the total
  #    number of pages, search for a rel="last" link, and then loop
  #    over all the pages.
  #
  # 2. We can ask for the header info with every single curl request,
  #    search for a rel="next" link to follow to the next page, and
  #    then parse out the body from the header.
  #
  # Although (1) is simpler, we choose to do (2) to save an extra API
  # call per invocation of curl.
  while [ ! -z "${url}" ]; do
    response="$(curl -si "${url}")"
    # we search for something like 'link: <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="next", <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="last"' and take the first 'next' url
    url="$(echo "${response}" | grep -m 1 -io '^link: .*>; rel="next"' | grep -o '<[^>]*>; rel="next"' | grep -o '<[^>]*>' | sed s'/[<>]//g')"
    echo "${response}" |
      {
        is_header="yes"
        while read line; do
          if [ "${is_header}" == "yes" ]; then
            if echo "${line}" | grep -q '^\s*[\[{]'; then # we treat lines beginning with [ or { as the beginning of the response body
              is_header="no"
              echo "${line}"
            fi
          else
            echo "${line}"
          fi
        done
      }
  done
}

Kind: bug fix / infrastructure.

view this post on Zulip Coq Github Bot (May 19 2020 at 20:01):

gasparattila edited PR #12366 Delay evaluating arguments of the "exists" tactic from fix-exists to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: bug fix

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #12365

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 19 2020 at 20:03):

ejgallego assigned [PR #12362 Use dev version for opam git pinning in .gitlab-ci.yml.](https://github.com/coq/coq/pull/12362 to ejgallego.

view this post on Zulip Coq Github Bot (May 19 2020 at 20:06):

ppedrot submitted PR Review for #12354 [universes] [api] Provide UState.from_env.

view this post on Zulip Coq Github Bot (May 19 2020 at 20:09):

ppedrot submitted PR Review for #12366 Delay evaluating arguments of the "exists" tactic.

view this post on Zulip Coq Github Bot (May 19 2020 at 20:09):

ppedrot created PR Review Comment on #12366 Delay evaluating arguments of the "exists" tactic:

You should probably move this definition to tactics.ml. It is not recommended to have code in mlg, despite the current situation.

view this post on Zulip Coq Github Bot (May 19 2020 at 20:12):

JasonGross opened PR #12368 Print a newline at the end of timing tables from fix-missing-newline-time-file-maker to master:

This, for example, improves the CI display, so that $ echo 'end:coq.test' does not appear on the same line as the end of the
timing table.

Kind: bug fix

view this post on Zulip Coq Github Bot (May 19 2020 at 20:12):

JasonGross milestoned Issue #12368 Print a newline at the end of timing tables:

This, for example, improves the CI display, so that $ echo 'end:coq.test' does not appear on the same line as the end of the
timing table.

Kind: bug fix

view this post on Zulip Coq Github Bot (May 19 2020 at 20:12):

JasonGross requested coq-makefile-maintainers for a review on PR #12368 Print a newline at the end of timing tables.

view this post on Zulip Coq Github Bot (May 19 2020 at 20:14):

JasonGross edited PR #12368 Print a newline at the end of timing tables from fix-missing-newline-time-file-maker to master:

This, for example, improves the CI display, so that $ echo 'end:coq.test' does not appear on the same line as the end of the
timing table.

Kind: bug fix

view this post on Zulip Coq Github Bot (May 19 2020 at 20:14):

JasonGross updated PR #12368 Print a newline at the end of timing tables from fix-missing-newline-time-file-maker to master:

This, for example, improves the CI display, so that $ echo 'end:coq.test' does not appear on the same line as the end of the
timing table.

Kind: bug fix

view this post on Zulip Coq Github Bot (May 19 2020 at 20:15):

ejgallego updated PR #12357 [declare] Remove some unused fix_exn from proof+no_fix_exn to master:

In the current proof save path, the kernel can raise an exception when
checking a proof wrapped into a future.

However, in this case, the future itself will "fix" the produced
exception, with the mandatory handler set at the future's creation
time.

Thus, there is no need for the declare layer to mess with exceptions
anymore, if my logic is correct. Note that the fix_exn parameter to
the Declare API was not used anymore.

This undoes 77cf18eb844b45776b2ec67be9f71e8dd4ca002c which comes from
pre-github times, so unfortunately I didn't have access to the
discussion.

We need to be careful in perform_buildp as to catch the Qed error
and properly notify the STM about it with State.exn_on; this was
previously done by the declare layer using a hack [grabbing internal
state of the future, that the future itself was not using as it was
already forced], but we now do it in the caller in a more principled
way.

This has been tested in the case that tactics succeed but Qed fails
asynchronously.

view this post on Zulip Coq Github Bot (May 19 2020 at 20:23):

jfehrle opened PR #12369 Handle conversion inconsistency between html and pdf for ids= and names= from fix_pdf_names to master:

Fixes #12361

view this post on Zulip Coq Github Bot (May 19 2020 at 20:23):

jfehrle milestoned Issue #12369 Handle conversion inconsistency between html and pdf for ids= and names=

Fixes #12361

view this post on Zulip Coq Github Bot (May 19 2020 at 20:24):

gasparattila requested tactics-maintainers for a review on PR #12366 Delay evaluating arguments of the "exists" tactic.

view this post on Zulip Coq Github Bot (May 19 2020 at 20:24):

gasparattila updated PR #12366 Delay evaluating arguments of the "exists" tactic from fix-exists to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: bug fix

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #12365

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 19 2020 at 20:26):

gasparattila submitted PR Review for #12366 Delay evaluating arguments of the "exists" tactic.

view this post on Zulip Coq Github Bot (May 19 2020 at 20:26):

gasparattila created PR Review Comment on #12366 Delay evaluating arguments of the "exists" tactic:

Done.

view this post on Zulip Coq Github Bot (May 19 2020 at 20:52):

cpitclaudel opened Issue #12370 Level is already declared right associative when importing a module:

Description of the problem

Notation level errors are sometimes delayed until a module is imported. For example, save this as Vect.v:

Require Import Coq.omega.Omega.

Notation "'Ob'" := 0 (at level 7).
Notation "bs '~' b" := (b + bs) (at level 7, left associativity, format "bs '~' b").
Notation "bs '~' 0" := (0 + bs) (at level 7, left associativity, format "bs '~' 0").
Notation "bs '~' 1" := (1 + bs) (at level 7, left associativity, format "bs '~' 1").

Then run coqc Vect.v (no problem) and try to import Vect:

Fail Require Import Vect.
(* The command has indeed failed with message: *)
(* Level 7 is already declared right associative while it is now expected to be left associative. *)

For some reason, importing NArith fixes the issue:

Require Import Coq.omega.Omega.
Require Export Coq.NArith.NArith.

Notation "'Ob'" := 0 (at level 7).
Notation "bs '~' b" := (b + bs) (at level 7, left associativity, format "bs '~' b").
Notation "bs '~' 0" := (0 + bs) (at level 7, left associativity, format "bs '~' 0").
Notation "bs '~' 1" := (1 + bs) (at level 7, left associativity, format "bs '~' 1").

… but not fully: Require Import Vect works, but Require Import Vect Vect still fails:

Fail Require Import Vect Vect.
(* The command has indeed failed with message: *)
(* Level 7 is already declared right associative while it is now expected to be left associative. *)
Require Import Vect.

Vect doesn't need to be imported twice explicitly: it's enough to import it twice indirectly, by importing two files that import it.

Coq Version

The Coq Proof Assistant, version 8.11.1 (May 2020)
compiled on May 19 2020 16:50:51 with OCaml 4.09.0

Linux Mint 19.3 Tricia

view this post on Zulip Coq Github Bot (May 19 2020 at 20:52):

cpitclaudel edited Issue #12370 "Level is already declared right associative" when importing a module:

Description of the problem

Notation level errors are sometimes delayed until a module is imported. For example, save this as Vect.v:

Require Import Coq.omega.Omega.

Notation "'Ob'" := 0 (at level 7).
Notation "bs '~' b" := (b + bs) (at level 7, left associativity, format "bs '~' b").
Notation "bs '~' 0" := (0 + bs) (at level 7, left associativity, format "bs '~' 0").
Notation "bs '~' 1" := (1 + bs) (at level 7, left associativity, format "bs '~' 1").

Then run coqc Vect.v (no problem) and try to import Vect:

Fail Require Import Vect.
(* The command has indeed failed with message: *)
(* Level 7 is already declared right associative while it is now expected to be left associative. *)

For some reason, importing NArith fixes the issue:

Require Import Coq.omega.Omega.
Require Export Coq.NArith.NArith.

Notation "'Ob'" := 0 (at level 7).
Notation "bs '~' b" := (b + bs) (at level 7, left associativity, format "bs '~' b").
Notation "bs '~' 0" := (0 + bs) (at level 7, left associativity, format "bs '~' 0").
Notation "bs '~' 1" := (1 + bs) (at level 7, left associativity, format "bs '~' 1").

… but not fully: Require Import Vect works, but Require Import Vect Vect still fails:

Fail Require Import Vect Vect.
(* The command has indeed failed with message: *)
(* Level 7 is already declared right associative while it is now expected to be left associative. *)
Require Import Vect.

Vect doesn't need to be imported twice explicitly: it's enough to import it twice indirectly, by importing two files that import it.

Coq Version

The Coq Proof Assistant, version 8.11.1 (May 2020)
compiled on May 19 2020 16:50:51 with OCaml 4.09.0

Linux Mint 19.3 Tricia

view this post on Zulip Coq Github Bot (May 19 2020 at 20:53):

cpitclaudel labeled Issue #12370 "Level is already declared right associative" when importing a module:

Description of the problem

Notation level errors are sometimes delayed until a module is imported. For example, save this as Vect.v:

Require Import Coq.omega.Omega.

Notation "'Ob'" := 0 (at level 7).
Notation "bs '~' b" := (b + bs) (at level 7, left associativity, format "bs '~' b").
Notation "bs '~' 0" := (0 + bs) (at level 7, left associativity, format "bs '~' 0").
Notation "bs '~' 1" := (1 + bs) (at level 7, left associativity, format "bs '~' 1").

Then run coqc Vect.v (no problem) and try to import Vect:

Fail Require Import Vect.
(* The command has indeed failed with message: *)
(* Level 7 is already declared right associative while it is now expected to be left associative. *)

For some reason, importing NArith fixes the issue:

Require Import Coq.omega.Omega.
Require Export Coq.NArith.NArith.

Notation "'Ob'" := 0 (at level 7).
Notation "bs '~' b" := (b + bs) (at level 7, left associativity, format "bs '~' b").
Notation "bs '~' 0" := (0 + bs) (at level 7, left associativity, format "bs '~' 0").
Notation "bs '~' 1" := (1 + bs) (at level 7, left associativity, format "bs '~' 1").

… but not fully: Require Import Vect works, but Require Import Vect Vect still fails:

Fail Require Import Vect Vect.
(* The command has indeed failed with message: *)
(* Level 7 is already declared right associative while it is now expected to be left associative. *)
Require Import Vect.

Vect doesn't need to be imported twice explicitly: it's enough to import it twice indirectly, by importing two files that import it.

Coq Version

The Coq Proof Assistant, version 8.11.1 (May 2020)
compiled on May 19 2020 16:50:51 with OCaml 4.09.0

Linux Mint 19.3 Tricia

view this post on Zulip Coq Github Bot (May 19 2020 at 20:53):

cpitclaudel labeled Issue #12370 "Level is already declared right associative" when importing a module:

Description of the problem

Notation level errors are sometimes delayed until a module is imported. For example, save this as Vect.v:

Require Import Coq.omega.Omega.

Notation "'Ob'" := 0 (at level 7).
Notation "bs '~' b" := (b + bs) (at level 7, left associativity, format "bs '~' b").
Notation "bs '~' 0" := (0 + bs) (at level 7, left associativity, format "bs '~' 0").
Notation "bs '~' 1" := (1 + bs) (at level 7, left associativity, format "bs '~' 1").

Then run coqc Vect.v (no problem) and try to import Vect:

Fail Require Import Vect.
(* The command has indeed failed with message: *)
(* Level 7 is already declared right associative while it is now expected to be left associative. *)

For some reason, importing NArith fixes the issue:

Require Import Coq.omega.Omega.
Require Export Coq.NArith.NArith.

Notation "'Ob'" := 0 (at level 7).
Notation "bs '~' b" := (b + bs) (at level 7, left associativity, format "bs '~' b").
Notation "bs '~' 0" := (0 + bs) (at level 7, left associativity, format "bs '~' 0").
Notation "bs '~' 1" := (1 + bs) (at level 7, left associativity, format "bs '~' 1").

… but not fully: Require Import Vect works, but Require Import Vect Vect still fails:

Fail Require Import Vect Vect.
(* The command has indeed failed with message: *)
(* Level 7 is already declared right associative while it is now expected to be left associative. *)
Require Import Vect.

Vect doesn't need to be imported twice explicitly: it's enough to import it twice indirectly, by importing two files that import it.

Coq Version

The Coq Proof Assistant, version 8.11.1 (May 2020)
compiled on May 19 2020 16:50:51 with OCaml 4.09.0

Linux Mint 19.3 Tricia

view this post on Zulip Coq Github Bot (May 19 2020 at 21:02):

Zimmi48 updated PR #12355 [8.12] Use pinned commits in dev/ci/ci-user-overlays.sh. (assigned to ejgallego) from pin-overlays to v8.12:

Kind: infrastructure.

While preparing this PR (by running dev/tools/pin-ci.sh), I have discovered that our referenced URL to coq-menhirlib (only used in the Windows build AFAIR) does not exist anymore. This likely means that the full Windows is currently failing. It looks like coq-menhirlib is now developed at https://gitlab.inria.fr/fpottier/menhir/-/tree/master/coq-menhirlib.

cc @MSoegtropIMC

view this post on Zulip Coq Github Bot (May 19 2020 at 22:04):

erikmd submitted PR Review for #12362 Use dev version for opam git pinning in .gitlab-ci.yml.

view this post on Zulip Coq Github Bot (May 19 2020 at 22:10):

ejgallego submitted PR Review for #12362 Use dev version for opam git pinning in .gitlab-ci.yml.

view this post on Zulip Coq Github Bot (May 19 2020 at 22:11):

ejgallego opened PR #12371 [obligations] Minor refactoring from obligations+more_ref to master:

Minors bits here and there, mostly self-explanatory.

view this post on Zulip Coq Github Bot (May 19 2020 at 22:11):

ejgallego requested vernac-maintainers for a review on PR #12371 [obligations] Minor refactoring.

view this post on Zulip Coq Github Bot (May 19 2020 at 22:12):

ejgallego milestoned Issue #12371 [obligations] Minor refactoring:

Minors bits here and there, mostly self-explanatory.

view this post on Zulip Coq Github Bot (May 19 2020 at 22:13):

ejgallego pushed 2 commits to branch master. Commits by Zimmi48 (1) and ejgallego (1).

view this post on Zulip Coq Github Bot (May 19 2020 at 22:13):

ejgallego merged PR #12362 Use dev version for opam git pinning in .gitlab-ci.yml.

view this post on Zulip Coq Github Bot (May 19 2020 at 22:29):

ejgallego opened PR #12372 [declare] Refactor constant information into a record. from proof+info to master:

This improves the interface, and allows even more sealing of the API.

This is yet work in progress.

view this post on Zulip Coq Github Bot (May 19 2020 at 22:38):

ejgallego updated PR #12372 [declare] Refactor constant information into a record. from proof+info to master:

This improves the interface, and allows even more sealing of the API.

This is yet work in progress.

view this post on Zulip Coq Github Bot (May 19 2020 at 22:48):

ejgallego updated PR #12372 [declare] Refactor constant information into a record. from proof+info to master:

This improves the interface, and allows even more sealing of the API.

This is yet work in progress.

view this post on Zulip Coq Github Bot (May 19 2020 at 23:30):

ejgallego updated PR #12372 [declare] Refactor constant information into a record. from proof+info to master:

This improves the interface, and allows even more sealing of the API.

This is yet work in progress.

view this post on Zulip Coq Github Bot (May 20 2020 at 00:35):

pi8027 submitted PR Review for #11906 [micromega] native support for boolean operators.

view this post on Zulip Coq Github Bot (May 20 2020 at 00:35):

pi8027 submitted PR Review for #11906 [micromega] native support for boolean operators.

view this post on Zulip Coq Github Bot (May 20 2020 at 00:35):

pi8027 created PR Review Comment on #11906 [micromega] native support for boolean operators:

Shouldn't this deprecation of Add Spec be documented in CHANGELOG?

view this post on Zulip Coq Github Bot (May 20 2020 at 00:35):

pi8027 created PR Review Comment on #11906 [micromega] native support for boolean operators:

Does TBOpInj := fun _ _ => eq_refl make this more robust?

view this post on Zulip Coq Github Bot (May 20 2020 at 00:35):

pi8027 created PR Review Comment on #11906 [micromega] native support for boolean operators:

I think this change should be reverted.

view this post on Zulip Coq Github Bot (May 20 2020 at 00:35):

pi8027 created PR Review Comment on #11906 [micromega] native support for boolean operators:

Same as above.

view this post on Zulip Coq Github Bot (May 20 2020 at 01:34):

cpitclaudel opened Issue #12373 Documentation request for printing levels and associativity:

Description of the problem

The following code (example by @kyoDralliam) creates two notations at the same level, with left associativity. The second one fails, complaining that level 8 is right associative. I couldn't find documentation about this in the manual:

Notation "'A' x 'A'" := (x + x) (at level 8, left associativity).
Fail Notation "'B' x" := (x + x) (at level 8, left associativity).

After processing the first notation, Print Grammar Constr shows this:

| "8" RIGHTA
  [  "A"; constr:operconstr LEVEL "200";  "A" ]

So presumably the first notation should have failed? Relatedly, Print Grammar Constr show this for level 9:

| "9" LEFTA
  [  ".."; constr:operconstr LEVEL "0";  ".." ]

Yet Notation "'A' x" := (x + x) (at level 9, left associativity). fails, complaining that level 9 is right-associative. What do LEFTA and RIGHTA mean, and why does the previous example fail?

Thanks!

Coq Version

The Coq Proof Assistant, version 8.11.1 (May 2020)
compiled on May 19 2020 16:50:51 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 20 2020 at 01:34):

cpitclaudel labeled Issue #12373 Documentation request for printing levels and associativity:

Description of the problem

The following code (example by @kyoDralliam) creates two notations at the same level, with left associativity. The second one fails, complaining that level 8 is right associative. I couldn't find documentation about this in the manual:

Notation "'A' x 'A'" := (x + x) (at level 8, left associativity).
Fail Notation "'B' x" := (x + x) (at level 8, left associativity).

After processing the first notation, Print Grammar Constr shows this:

| "8" RIGHTA
  [  "A"; constr:operconstr LEVEL "200";  "A" ]

So presumably the first notation should have failed? Relatedly, Print Grammar Constr show this for level 9:

| "9" LEFTA
  [  ".."; constr:operconstr LEVEL "0";  ".." ]

Yet Notation "'A' x" := (x + x) (at level 9, left associativity). fails, complaining that level 9 is right-associative. What do LEFTA and RIGHTA mean, and why does the previous example fail?

Thanks!

Coq Version

The Coq Proof Assistant, version 8.11.1 (May 2020)
compiled on May 19 2020 16:50:51 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 20 2020 at 01:34):

cpitclaudel labeled Issue #12373 Documentation request for printing levels and associativity:

Description of the problem

The following code (example by @kyoDralliam) creates two notations at the same level, with left associativity. The second one fails, complaining that level 8 is right associative. I couldn't find documentation about this in the manual:

Notation "'A' x 'A'" := (x + x) (at level 8, left associativity).
Fail Notation "'B' x" := (x + x) (at level 8, left associativity).

After processing the first notation, Print Grammar Constr shows this:

| "8" RIGHTA
  [  "A"; constr:operconstr LEVEL "200";  "A" ]

So presumably the first notation should have failed? Relatedly, Print Grammar Constr show this for level 9:

| "9" LEFTA
  [  ".."; constr:operconstr LEVEL "0";  ".." ]

Yet Notation "'A' x" := (x + x) (at level 9, left associativity). fails, complaining that level 9 is right-associative. What do LEFTA and RIGHTA mean, and why does the previous example fail?

Thanks!

Coq Version

The Coq Proof Assistant, version 8.11.1 (May 2020)
compiled on May 19 2020 16:50:51 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 20 2020 at 01:34):

cpitclaudel labeled Issue #12373 Documentation request for printing levels and associativity:

Description of the problem

The following code (example by @kyoDralliam) creates two notations at the same level, with left associativity. The second one fails, complaining that level 8 is right associative. I couldn't find documentation about this in the manual:

Notation "'A' x 'A'" := (x + x) (at level 8, left associativity).
Fail Notation "'B' x" := (x + x) (at level 8, left associativity).

After processing the first notation, Print Grammar Constr shows this:

| "8" RIGHTA
  [  "A"; constr:operconstr LEVEL "200";  "A" ]

So presumably the first notation should have failed? Relatedly, Print Grammar Constr show this for level 9:

| "9" LEFTA
  [  ".."; constr:operconstr LEVEL "0";  ".." ]

Yet Notation "'A' x" := (x + x) (at level 9, left associativity). fails, complaining that level 9 is right-associative. What do LEFTA and RIGHTA mean, and why does the previous example fail?

Thanks!

Coq Version

The Coq Proof Assistant, version 8.11.1 (May 2020)
compiled on May 19 2020 16:50:51 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 20 2020 at 01:39):

pi8027 submitted PR Review for #11906 [micromega] native support for boolean operators.

view this post on Zulip Coq Github Bot (May 20 2020 at 01:39):

pi8027 created PR Review Comment on #11906 [micromega] native support for boolean operators:

Actually micromega.rst has not been updated accordingly.

view this post on Zulip Coq Github Bot (May 20 2020 at 02:57):

jfehrle updated PR #12369 Handle conversion inconsistency between html and pdf for ids= and names= from fix_pdf_names to master:

Fixes #12361

view this post on Zulip Coq Github Bot (May 20 2020 at 08:57):

lthms opened Issue #12374 [extraction] Allow to customize primitive integers init function:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Currently, when one uses primitive integers and extraction, they has to provide a Uint63 module with at least a of_int function. Neither this function name nor the module name is customizable.

Coq Version

Relevant for any version of Coq with native integers support.

view this post on Zulip Coq Github Bot (May 20 2020 at 08:58):

lthms edited Issue #12374 [extraction] Allow to customize primitive integers init function:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Currently, when one uses primitive integers and extraction, they has to provide a Uint63 module with at least a of_int function. Neither this function name nor the module name is customizable.

The string in currently hard-coded in Uint63.compile; I believe it would be a good idea to provide two options (one for the module name, one for the function name).

Coq Version

Relevant for any version of Coq with native integers support.

view this post on Zulip Coq Github Bot (May 20 2020 at 09:56):

Zimmi48 edited PR #12363 [8.12] Tweak the OCaml version used to generate the MacOS package. (assigned to ejgallego) from macos-binary-8.12 to v8.12:

(cherry picked from commit 45432df10d92b090fe3aaa3cc2f99c006fe621a6)

cf. #12310

view this post on Zulip Coq Github Bot (May 20 2020 at 10:00):

ejgallego:

view this post on Zulip Coq Github Bot (May 20 2020 at 10:16):

Zimmi48 updated PR #12355 [8.12] Use pinned commits in dev/ci/ci-user-overlays.sh. (assigned to ejgallego) from pin-overlays to v8.12:

Kind: infrastructure.

While preparing this PR (by running dev/tools/pin-ci.sh), I have discovered that our referenced URL to coq-menhirlib (only used in the Windows build AFAIR) does not exist anymore. This likely means that the full Windows is currently failing. It looks like coq-menhirlib is now developed at https://gitlab.inria.fr/fpottier/menhir/-/tree/master/coq-menhirlib.

cc @MSoegtropIMC

view this post on Zulip Coq Github Bot (May 20 2020 at 10:22):

Zimmi48 opened Issue #12375 Not the right version of Elpi in nixpkgs:

I tried using dev/ci/nix/shell Elpi but I got Elpi 1.10 whereas 1.11 is required. Elpi has not been updated yet on nixpkgs. I tried a naive patch but it didn't work:

diff --git a/pkgs/development/ocaml-modules/elpi/default.nix b/pkgs/development/ocaml-modules/elpi/default.nix
index 1c71f7fceb7..3a87caa36f2 100644
--- a/pkgs/development/ocaml-modules/elpi/default.nix
+++ b/pkgs/development/ocaml-modules/elpi/default.nix
@@ -1,20 +1,20 @@
-{ lib, fetchFromGitHub, buildDunePackage, camlp5
+{ lib, fetchzip, buildDunePackage, camlp5
 , ppx_tools_versioned, ppx_deriving, re
 }:

 buildDunePackage rec {
   pname = "elpi";

-  version = "1.10.2";
+  version = "1.11.2";


-  src = fetchFromGitHub {
-    owner = "LPCIC";
-    repo = "elpi";
-    rev = "v${version}";
-    sha256 = "0w5z0pxyshqawq7w5rw3nqii49y88rizvwqf202pl11xqi14icsn";
+  src = fetchzip {
+    url = "https://github.com/LPCIC/elpi/releases/download/v${version}/elpi-v${version}.tbz";
+    sha256 = "15hamy9ifr05kczadwh3yj2gmr12a9z1jwppmp5yrns0vykjbj76";
   };

   minimumOCamlVersion = "4.04";


+  useDune2 = true;
+
   buildInputs = [ ppx_tools_versioned ];

   propagatedBuildInputs = [ camlp5 ppx_deriving re ];

The error is:

builder for '/nix/store/pn9lfynrhjy8zx417njmsp63gpichzzc-ocaml4.09.1-elpi-1.11.0.drv' failed with exit code 1; last 10 log lines:
  (cd _build/default && /nix/store/s37qwaqzi246z8fl3jpv016j8dzfwmig-ocaml-4.09.1/bin/ocamlc.opt -linkall -g -bin-annot -I src/.elpi.objs/byte -I src/.elpi.objs/public_cmi -I /nix/store/0x5vdncjs78xihrjq64s52nsq47m3m9y-ocaml4.09.1-seq-0.1/lib/ocaml/4.09.1/site-lib/seq -I /nix/store/3f6xxwh0gsmqnkfcakkb1qfavcagcbah-ocaml4.09.1-result-1.2/lib/ocaml/4.09.1/site-lib/result -I /nix/store/93jg6hkvpkmbc0mihi0wb9qjpwp62fkj-camlp5-7.11/lib/ocaml/4.09.1/site-lib/camlp5 -I /nix/store/d81rk58irb3q08q5hh02jl215p73vbbi-ocaml4.09.1-ppx_deriving-4.4.1/lib/ocaml/4.09.1/site-lib/ppx_deriving/runtime -I /nix/store/k318j0m9r84y31kkg5cckkk447qh2zij-ocaml4.09.1-re-1.9.0/lib/ocaml/4.09.1/site-lib/re -I /nix/store/k318j0m9r84y31kkg5cckkk447qh2zij-ocaml4.09.1-re-1.9.0/lib/ocaml/4.09.1/site-lib/re/str -I trace/runtime/.trace_ppx_runtime.objs/byte -I trace/runtime/.trace_ppx_runtime.objs/native -no-alias-deps -open Elpi__ -o src/.elpi.objs/byte/elpi__Runtime_trace_off.cmi -c -intf src/runtime_trace_off.pp.mli)
  File "src/runtime_trace_off.mli", line 6, characters 12-18:
  Error: Unbound type constructor pp_ctx
        ocamlc src/.elpi.objs/byte/elpi__Builtin.{cmi,cmti} (exit 2)
  (cd _build/default && /nix/store/s37qwaqzi246z8fl3jpv016j8dzfwmig-ocaml-4.09.1/bin/ocamlc.opt -linkall -g -bin-annot -I src/.elpi.objs/byte -I src/.elpi.objs/public_cmi -I /nix/store/0x5vdncjs78xihrjq64s52nsq47m3m9y-ocaml4.09.1-seq-0.1/lib/ocaml/4.09.1/site-lib/seq -I /nix/store/3f6xxwh0gsmqnkfcakkb1qfavcagcbah-ocaml4.09.1-result-1.2/lib/ocaml/4.09.1/site-lib/result -I /nix/store/93jg6hkvpkmbc0mihi0wb9qjpwp62fkj-camlp5-7.11/lib/ocaml/4.09.1/site-lib/camlp5 -I /nix/store/d81rk58irb3q08q5hh02jl215p73vbbi-ocaml4.09.1-ppx_deriving-4.4.1/lib/ocaml/4.09.1/site-lib/ppx_deriving/runtime -I /nix/store/k318j0m9r84y31kkg5cckkk447qh2zij-ocaml4.09.1-re-1.9.0/lib/ocaml/4.09.1/site-lib/re -I /nix/store/k318j0m9r84y31kkg5cckkk447qh2zij-ocaml4.09.1-re-1.9.0/lib/ocaml/4.09.1/site-lib/re/str -I trace/runtime/.trace_ppx_runtime.objs/byte -I trace/runtime/.trace_ppx_runtime.objs/native -no-alias-deps -open Elpi__ -o src/.elpi.objs/byte/elpi__Builtin.cmi -c -intf src/builtin.mli)
  File "src/builtin.mli", line 7, characters 5-16:
  7 | open API.BuiltIn
           ^^^^^^^^^^^
  Error: Unbound module API.BuiltIn

cc @vbgl and @gares

view this post on Zulip Coq Github Bot (May 20 2020 at 10:22):

Zimmi48 labeled Issue #12375 Not the right version of Elpi in nixpkgs:

I tried using dev/ci/nix/shell Elpi but I got Elpi 1.10 whereas 1.11 is required. Elpi has not been updated yet on nixpkgs. I tried a naive patch but it didn't work:

diff --git a/pkgs/development/ocaml-modules/elpi/default.nix b/pkgs/development/ocaml-modules/elpi/default.nix
index 1c71f7fceb7..3a87caa36f2 100644
--- a/pkgs/development/ocaml-modules/elpi/default.nix
+++ b/pkgs/development/ocaml-modules/elpi/default.nix
@@ -1,20 +1,20 @@
-{ lib, fetchFromGitHub, buildDunePackage, camlp5
+{ lib, fetchzip, buildDunePackage, camlp5
 , ppx_tools_versioned, ppx_deriving, re
 }:

 buildDunePackage rec {
   pname = "elpi";

-  version = "1.10.2";
+  version = "1.11.2";


-  src = fetchFromGitHub {
-    owner = "LPCIC";
-    repo = "elpi";
-    rev = "v${version}";
-    sha256 = "0w5z0pxyshqawq7w5rw3nqii49y88rizvwqf202pl11xqi14icsn";
+  src = fetchzip {
+    url = "https://github.com/LPCIC/elpi/releases/download/v${version}/elpi-v${version}.tbz";
+    sha256 = "15hamy9ifr05kczadwh3yj2gmr12a9z1jwppmp5yrns0vykjbj76";
   };

   minimumOCamlVersion = "4.04";


+  useDune2 = true;
+
   buildInputs = [ ppx_tools_versioned ];

   propagatedBuildInputs = [ camlp5 ppx_deriving re ];

The error is:

builder for '/nix/store/pn9lfynrhjy8zx417njmsp63gpichzzc-ocaml4.09.1-elpi-1.11.0.drv' failed with exit code 1; last 10 log lines:
  (cd _build/default && /nix/store/s37qwaqzi246z8fl3jpv016j8dzfwmig-ocaml-4.09.1/bin/ocamlc.opt -linkall -g -bin-annot -I src/.elpi.objs/byte -I src/.elpi.objs/public_cmi -I /nix/store/0x5vdncjs78xihrjq64s52nsq47m3m9y-ocaml4.09.1-seq-0.1/lib/ocaml/4.09.1/site-lib/seq -I /nix/store/3f6xxwh0gsmqnkfcakkb1qfavcagcbah-ocaml4.09.1-result-1.2/lib/ocaml/4.09.1/site-lib/result -I /nix/store/93jg6hkvpkmbc0mihi0wb9qjpwp62fkj-camlp5-7.11/lib/ocaml/4.09.1/site-lib/camlp5 -I /nix/store/d81rk58irb3q08q5hh02jl215p73vbbi-ocaml4.09.1-ppx_deriving-4.4.1/lib/ocaml/4.09.1/site-lib/ppx_deriving/runtime -I /nix/store/k318j0m9r84y31kkg5cckkk447qh2zij-ocaml4.09.1-re-1.9.0/lib/ocaml/4.09.1/site-lib/re -I /nix/store/k318j0m9r84y31kkg5cckkk447qh2zij-ocaml4.09.1-re-1.9.0/lib/ocaml/4.09.1/site-lib/re/str -I trace/runtime/.trace_ppx_runtime.objs/byte -I trace/runtime/.trace_ppx_runtime.objs/native -no-alias-deps -open Elpi__ -o src/.elpi.objs/byte/elpi__Runtime_trace_off.cmi -c -intf src/runtime_trace_off.pp.mli)
  File "src/runtime_trace_off.mli", line 6, characters 12-18:
  Error: Unbound type constructor pp_ctx
        ocamlc src/.elpi.objs/byte/elpi__Builtin.{cmi,cmti} (exit 2)
  (cd _build/default && /nix/store/s37qwaqzi246z8fl3jpv016j8dzfwmig-ocaml-4.09.1/bin/ocamlc.opt -linkall -g -bin-annot -I src/.elpi.objs/byte -I src/.elpi.objs/public_cmi -I /nix/store/0x5vdncjs78xihrjq64s52nsq47m3m9y-ocaml4.09.1-seq-0.1/lib/ocaml/4.09.1/site-lib/seq -I /nix/store/3f6xxwh0gsmqnkfcakkb1qfavcagcbah-ocaml4.09.1-result-1.2/lib/ocaml/4.09.1/site-lib/result -I /nix/store/93jg6hkvpkmbc0mihi0wb9qjpwp62fkj-camlp5-7.11/lib/ocaml/4.09.1/site-lib/camlp5 -I /nix/store/d81rk58irb3q08q5hh02jl215p73vbbi-ocaml4.09.1-ppx_deriving-4.4.1/lib/ocaml/4.09.1/site-lib/ppx_deriving/runtime -I /nix/store/k318j0m9r84y31kkg5cckkk447qh2zij-ocaml4.09.1-re-1.9.0/lib/ocaml/4.09.1/site-lib/re -I /nix/store/k318j0m9r84y31kkg5cckkk447qh2zij-ocaml4.09.1-re-1.9.0/lib/ocaml/4.09.1/site-lib/re/str -I trace/runtime/.trace_ppx_runtime.objs/byte -I trace/runtime/.trace_ppx_runtime.objs/native -no-alias-deps -open Elpi__ -o src/.elpi.objs/byte/elpi__Builtin.cmi -c -intf src/builtin.mli)
  File "src/builtin.mli", line 7, characters 5-16:
  7 | open API.BuiltIn
           ^^^^^^^^^^^
  Error: Unbound module API.BuiltIn

cc @vbgl and @gares

view this post on Zulip Coq Github Bot (May 20 2020 at 10:42):

ejgallego requested ci-maintainers and nix-maintainers for a review on PR #12364 [ci] [docker] Bump ocamlformat and dune.

view this post on Zulip Coq Github Bot (May 20 2020 at 10:42):

Zimmi48 updated PR #12364 [ci] [docker] Bump ocamlformat and dune from ci+bump_deps to master:

cc: #12350

view this post on Zulip Coq Github Bot (May 20 2020 at 10:42):

Zimmi48 milestoned Issue #12364 [ci] [docker] Bump ocamlformat and dune:

cc: #12350

view this post on Zulip Coq Github Bot (May 20 2020 at 10:46):

Zimmi48 updated PR #12355 [8.12] Use pinned commits in dev/ci/ci-user-overlays.sh. (assigned to ejgallego) from pin-overlays to v8.12:

Kind: infrastructure.

While preparing this PR (by running dev/tools/pin-ci.sh), I have discovered that our referenced URL to coq-menhirlib (only used in the Windows build AFAIR) does not exist anymore. This likely means that the full Windows is currently failing. It looks like coq-menhirlib is now developed at https://gitlab.inria.fr/fpottier/menhir/-/tree/master/coq-menhirlib.

cc @MSoegtropIMC

view this post on Zulip Coq Github Bot (May 20 2020 at 11:31):

SkySkimmer milestoned Issue #12342 Direct URL for triggering a pipeline with SKIP_DOCKER=false. (assigned to SkySkimmer):

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: documentation

view this post on Zulip Coq Github Bot (May 20 2020 at 11:31):

SkySkimmer pushed 2 commits to branch master. Commits by SkySkimmer (1) and Zimmi48 (1).

view this post on Zulip Coq Github Bot (May 20 2020 at 11:31):

SkySkimmer merged PR #12342 Direct URL for triggering a pipeline with SKIP_DOCKER=false.

view this post on Zulip Coq Github Bot (May 20 2020 at 11:32):

SkySkimmer milestoned Issue #12354 [universes] [api] Provide UState.from_env (assigned to SkySkimmer):

This seems like a recurring pattern, and IMO makes a bit better API.

We also remove merge_universe_subst as it is not needed so far, as
we were creating stale evar_maps just for this purpose.

view this post on Zulip Coq Github Bot (May 20 2020 at 11:32):

SkySkimmer pushed 2 commits to branch master. Commits by SkySkimmer (1) and ejgallego (1).

view this post on Zulip Coq Github Bot (May 20 2020 at 11:32):

SkySkimmer merged PR #12354 [universes] [api] Provide UState.from_env.

view this post on Zulip Coq Github Bot (May 20 2020 at 11:32):

SkySkimmer milestoned Issue #12356 [declare] Remove unused parameters in prepare_obligation (assigned to SkySkimmer):

Cleanup PR.

view this post on Zulip Coq Github Bot (May 20 2020 at 11:33):

SkySkimmer pushed 4 commits to branch master. Commits by ejgallego (3) and SkySkimmer (1).

view this post on Zulip Coq Github Bot (May 20 2020 at 11:33):

SkySkimmer merged PR #12356 [declare] Remove unused parameters in prepare_obligation.

view this post on Zulip Coq Github Bot (May 20 2020 at 11:36):

SkySkimmer assigned PR #12364 [ci] [docker] Bump ocamlformat and dune to SkySkimmer.

view this post on Zulip Coq Github Bot (May 20 2020 at 11:36):

SkySkimmer submitted PR Review for #12364 [ci] [docker] Bump ocamlformat and dune.

view this post on Zulip Coq Github Bot (May 20 2020 at 11:38):

SkySkimmer pushed 2 commits to branch master. Commits by SkySkimmer (1) and ejgallego (1).

view this post on Zulip Coq Github Bot (May 20 2020 at 11:38):

SkySkimmer closed Issue #12264 Errors when running test suite with recent Dune. (assigned to ejgallego):

Description of the problem

When dune runtest, [build errors appear][log]. Some of them can be solved by [a few chmod invocations][patch]. [Other errors are then reached][log2] for which I have not found a solution. Test suite therefore fails.

[log]: https://gist.github.com/kindaro/d284b4e8bcc76aaefaba192ad2f3f371#file-dune-log
[patch]: https://gist.github.com/kindaro/d284b4e8bcc76aaefaba192ad2f3f371#file-fix-diff
[log2]: https://gist.github.com/kindaro/d284b4e8bcc76aaefaba192ad2f3f371#file-dune-2-log

My suspicion is that [the upgrade of _dune_][dune] has something to do with this.

[dune]: https://github.com/coq/coq/commit/bc411fa4d8c04424c579d506dd0507cb83db7bc7

Software versions

Coq Version

The Coq Proof Assistant, version 8.12+alpha (May 2020)
compiled on May 6 2020 4:32:32 with OCaml 4.09.0

Dune Version

2.5.0
2.5.1

Make Version

GNU Make 4.3
Built for x86_64-pc-linux-gnu

CSDP Version

Name            : coin-or-csdp
Version         : 6.2.0-3
Description     : A C library for Semidefinite Programming
Architecture    : x86_64

_(On Arch Linux.)_

view this post on Zulip Coq Github Bot (May 20 2020 at 11:38):

SkySkimmer merged PR #12350 [test-suite] Ensure copies of files are writable.

view this post on Zulip Coq Github Bot (May 20 2020 at 11:52):

gares opened Issue #12376 [dune] which version?

gares@ollypat:~/COQ/master$ git grep '\(lang\|dune\).*2\.[0-9]'
coq.opam:  "dune"      { >= "2.5.0"  }
coqide-server.opam:  "dune"      { >= "2.0.0" }
coqide.opam:  "dune"                 { >= "2.0.0" }
dev/build/windows/makecoq_mingw.sh:  if build_prep https://github.com/ocaml/dune/archive/ 2.0.0 tar.gz 1 dune-2.0.0 ; then
dev/ci/docker/bionic_coq/Dockerfile:    BASE_OPAM_EDGE="dune.2.5.0 dune-release.1.3.3 ocamlformat.0.14.0"
dev/dune-workspace.all:(lang dune 2.0)
dune-project:(lang dune 2.5)

I guess we should centralize this piece of info, one way or another, in order to avoid duplication.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:13):

SkySkimmer submitted PR Review for #12368 Print a newline at the end of timing tables.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:13):

SkySkimmer submitted PR Review for #12368 Print a newline at the end of timing tables.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:13):

SkySkimmer created PR Review Comment on #12368 Print a newline at the end of timing tables:

Github says this one still misses an end of file newline, is that normal?

view this post on Zulip Coq Github Bot (May 20 2020 at 12:14):

SkySkimmer assigned PR #12368 Print a newline at the end of timing tables to SkySkimmer.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:16):

SkySkimmer submitted PR Review for #12371 [obligations] Minor refactoring.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:16):

SkySkimmer created PR Review Comment on #12371 [obligations] Minor refactoring:

TBH I prefer typ to types as there's only 1
Also why don't we shadow here?

view this post on Zulip Coq Github Bot (May 20 2020 at 12:17):

SkySkimmer submitted PR Review for #12371 [obligations] Minor refactoring.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:17):

SkySkimmer created PR Review Comment on #12371 [obligations] Minor refactoring:

           if !showed > 0 then begin
             decr showed;
             show_single_obligation i n obls x
           end

slightly prettier imo

view this post on Zulip Coq Github Bot (May 20 2020 at 12:18):

SkySkimmer submitted PR Review for #12371 [obligations] Minor refactoring.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:18):

SkySkimmer assigned PR #12371 [obligations] Minor refactoring to SkySkimmer.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:20):

ejgallego updated PR #12371 [obligations] Minor refactoring (assigned to SkySkimmer) from obligations+more_ref to master:

Minors bits here and there, mostly self-explanatory.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:21):

ejgallego submitted PR Review for #12371 [obligations] Minor refactoring.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:21):

ejgallego created PR Review Comment on #12371 [obligations] Minor refactoring:

Shadowing done, I used types as this is what has been used on the rest of Declare; maybe #12372 would be a good opportunity to discuss a better naming overall.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:21):

ejgallego submitted PR Review for #12371 [obligations] Minor refactoring.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:21):

ejgallego created PR Review Comment on #12371 [obligations] Minor refactoring:

Done, thanks.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:23):

SkySkimmer submitted PR Review for #12359 [ci] Add mit-plv/engine-bench.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:23):

SkySkimmer assigned PR #12359 [ci] Add mit-plv/engine-bench to SkySkimmer.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:23):

SkySkimmer milestoned Issue #12359 [ci] Add mit-plv/engine-bench (assigned to SkySkimmer):

This is a new development where I'm aggregating a specific set of
benchmarks. It's intended to be relatively lightweight, taking only a
handful of minutes (I can make the CI target much, much lighter if
desired). It's probably one of the few developments currently testing
Ltac2.

Kind: infrastructure

view this post on Zulip Coq Github Bot (May 20 2020 at 12:24):

SkySkimmer pushed 2 commits to branch master. Commits by JasonGross (1) and SkySkimmer (1).

view this post on Zulip Coq Github Bot (May 20 2020 at 12:24):

SkySkimmer merged PR #12359 [ci] Add mit-plv/engine-bench.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:25):

SkySkimmer assigned PR #12358 [topfmt] Set formatter + flush fix to SkySkimmer.

view this post on Zulip Coq Github Bot (May 20 2020 at 12:26):

SkySkimmer submitted PR Review for #12358 [topfmt] Set formatter + flush fix.

view this post on Zulip Coq Github Bot (May 20 2020 at 13:35):

gares edited Issue #12334 Release 8.13 (assigned to maximedenes):

Release process

As soon as the previous version branched off master

In principle, these steps should be undertaken by the RM of the next
release. Unfortunately, we have not yet been able to nominate RMs
early enough in the process for this person to be known at that point
in time.

Anytime after the previous version is branched off master

About one month before the beta

On the date of the feature freeze

Before the beta release date

These steps are the same for all releases (beta, final, patch-level)

At the final release time

Repeat the generic process documented above for all releases.

Ping @Zimmi48 to:

At the patch-level release time

We generally do not update the magic numbers at this point (see
2881a18).

view this post on Zulip Coq Github Bot (May 20 2020 at 14:13):

fajb edited PR #11906 [micromega] native support for boolean operators from bmicromega to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

Kind: feature
(this is a clean revival of #11047 )

view this post on Zulip Coq Github Bot (May 20 2020 at 14:19):

SkySkimmer edited PR #11906 [micromega] native support for boolean operators from bmicromega to master:

Kind: feature
(this is a clean revival of #11047 )

view this post on Zulip Coq Github Bot (May 20 2020 at 14:24):

fajb updated PR #11906 [micromega] native support for boolean operators from bmicromega to master:

Kind: feature
(this is a clean revival of #11047 )

view this post on Zulip Coq Github Bot (May 20 2020 at 14:26):

fajb submitted PR Review for #11906 [micromega] native support for boolean operators.

view this post on Zulip Coq Github Bot (May 20 2020 at 14:26):

fajb created PR Review Comment on #11906 [micromega] native support for boolean operators:

The Add xxx are currently undocumented...

view this post on Zulip Coq Github Bot (May 20 2020 at 14:26):

fajb created PR Review Comment on #11906 [micromega] native support for boolean operators:

done.

view this post on Zulip Coq Github Bot (May 20 2020 at 14:26):

fajb submitted PR Review for #11906 [micromega] native support for boolean operators.

view this post on Zulip Coq Github Bot (May 20 2020 at 14:26):

fajb submitted PR Review for #11906 [micromega] native support for boolean operators.

view this post on Zulip Coq Github Bot (May 20 2020 at 14:26):

fajb created PR Review Comment on #11906 [micromega] native support for boolean operators:

done.

view this post on Zulip Coq Github Bot (May 20 2020 at 14:26):

fajb submitted PR Review for #11906 [micromega] native support for boolean operators.

view this post on Zulip Coq Github Bot (May 20 2020 at 14:26):

fajb created PR Review Comment on #11906 [micromega] native support for boolean operators:

done.

view this post on Zulip Coq Github Bot (May 20 2020 at 14:38):

vbgl submitted PR Review for #12364 [ci] [docker] Bump ocamlformat and dune.

view this post on Zulip Coq Github Bot (May 20 2020 at 15:03):

mattam82:

view this post on Zulip Coq Github Bot (May 20 2020 at 15:37):

JasonGross submitted PR Review for #12368 Print a newline at the end of timing tables.

view this post on Zulip Coq Github Bot (May 20 2020 at 15:37):

JasonGross created PR Review Comment on #12368 Print a newline at the end of timing tables:

Very strange, let me look into this

view this post on Zulip Coq Github Bot (May 20 2020 at 16:18):

ejgallego updated PR #12142 [proof] Split vio and regular proof close paths. from proof+split_vio_save2 to master:

The paths don't have the same type, in particular the opaque argument
cannot be set to Transparent for close_vio_proof.

We could add an assert, but it seems easier just to do change the type.

This depends on #12130 and it is a continuation of #11915 and #11916 ; the code here originally was part of #11916 and included much more refactoring of common parts which fully mitigated the duplication introduced here. I will push these changes once the depending PR has been merged as the removal of Proof_global made the rebase impossible.

view this post on Zulip Coq Github Bot (May 20 2020 at 17:15):

proux01 updated PR #12218 Numeral notations for non inductive types from numeral-notations-non-inductive to master:

This is a tentative implementation of the idea discussed in #12035

This is a draft PR due to the fact that it is still lacking some proofs and proper documentation.

Numeral Notation non_inductive via inductive using ...

The main idea is to use actual inductive types that map what you want to parse/print and just translate to (resp. from) the actual type from (resp. to) this inductive type after calling the parser (resp before the printer). One then just has to provide a mapping from globrefs of the actual type to constructors of the inductive type.

For instance, for reals, that looks something like

Inductive IZ :=
| IZpow_pos : Z -> positive -> IZ
| IZ0 : IZ
| IZpos : positive -> IZ
| IZneg : positive -> IZ.

Inductive IR :=
| IRZ : IZ -> IR
| IRQ : Q -> IR
| IRmult : IR -> IR -> IR
| IRdiv : IR -> IR -> IR.

[..]  (* define parser numeral_to_IR and printer IR_to_numeral *)

Numeral Notation R via IR
  using (IZR IRZ, Q2R IRQ, Rmult IRmult, Rdiv IRdiv,
         Z.pow_pos IZpow_pos, Z0 IZ0, Zpos IZpos, Zneg IZneg)
  numeral_to_IR IR_to_numeral : R_scope.

Two notations are provided as examples for Q and R.

Q

Previously rationals were all parsed as a pair numerator, denominator. This means 1.02 and 102e-2 were both parsed as 102 # 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is still parsed as a power of ten denominator but exponents are parsed as a product or division by Z.pow_pos. For instance, 1.02 is parsed as 102 # 100 whereas 102e-2 is parsed as (102 # 1) / (Z.pow_pos 10 2 # 1).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = (102 # 100) * (10 # 1) = 1020 # 100 and 10.2 = 102 # 10 no longer are.

A nice side effect is that exponents can no longer blow up during parsing. Previously 1e1_000_000 literally produced a numerator with a million digits, now it just yields (1 # 1) * (Z.pow_pos 10 1_000_000 # 1).

R

Previously real constants were parsed by an unproved OCaml code. The parser and printer are now implemented in Coq, which will enable a proof and hopefully make it easier to maintain / make evolve.

Previously reals were all parsed as an integer, an integer multiplied by a power of ten or an integer divided by a power of ten. This means 1.02 and 102e-2 were both parsed as 102 / 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is parsed as a rational and exponents are parsed as a product or division by a power of ten. For instance, 1.02 is parsed as Q2R (102 # 100) whereas 102e-2 is parsed as IZR 102 / IZR (Z.pow_pos 10 2).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = Q2R (102 # 100) * 10 and 10.2 = Q2R (102 # 10) no longer are.

TODO

~Depends from: #11948~

view this post on Zulip Coq Github Bot (May 20 2020 at 17:17):

Zimmi48 milestoned Issue #12377 Adapt the documentation to the move from Gitter to Zulip.

Kind: documentation

view this post on Zulip Coq Github Bot (May 20 2020 at 17:17):

Zimmi48 opened PR #12377 Adapt the documentation to the move from Gitter to Zulip. from doc-zulip to master:

Kind: documentation

view this post on Zulip Coq Github Bot (May 20 2020 at 17:17):

Zimmi48 requested doc-maintainers, contributing-process-maintainers and code-of-conduct-team for a review on PR #12377 Adapt the documentation to the move from Gitter to Zulip..

view this post on Zulip Coq Github Bot (May 20 2020 at 17:17):

Zimmi48 requested doc-maintainers, contributing-process-maintainers and code-of-conduct-team for a review on PR #12377 Adapt the documentation to the move from Gitter to Zulip..

view this post on Zulip Coq Github Bot (May 20 2020 at 17:17):

Zimmi48 requested doc-maintainers, contributing-process-maintainers and code-of-conduct-team for a review on PR #12377 Adapt the documentation to the move from Gitter to Zulip..

view this post on Zulip Coq Github Bot (May 20 2020 at 17:38):

cpitclaudel submitted PR Review for #12377 Adapt the documentation to the move from Gitter to Zulip.

view this post on Zulip Coq Github Bot (May 20 2020 at 17:38):

cpitclaudel created PR Review Comment on #12377 Adapt the documentation to the move from Gitter to Zulip.

Poor coq-club, it's "historical" now

view this post on Zulip Coq Github Bot (May 20 2020 at 17:38):

cpitclaudel submitted PR Review for #12377 Adapt the documentation to the move from Gitter to Zulip.

view this post on Zulip Coq Github Bot (May 20 2020 at 17:44):

jfehrle updated PR #12369 Handle conversion inconsistency between html and pdf for ids= and names= from fix_pdf_names to master:

Fixes #12361

view this post on Zulip Coq Github Bot (May 20 2020 at 18:01):

andrew-appel opened Issue #12378 benign-looking 'replace' causes Qed to blow up:

Description of the problem

In Coq 8.11.1, a 'replace' command causes the Qed to blow up (I killed it after 1 hour), but without the 'replace', the Qed takes about 0.2 seconds.

That is: In my theorem, after 100 lines of nontrivial proof script (but the kind that is normally well within Coq's capacity), I come to this proof goal:

j, c : forall _ : environ, mpred
H7 : derives c j
______________________________________(1/1)
True

If I finish the proof with auto. Qed. then the Qed takes 0.22 seconds.
If I finish the proof with replace c with j in H7 by apply admit. auto. Qed. then the Qed takes more than an hour, if indeed it ever finishes.

The fact that I'm using a very generous Admitted lemma called admit is irrelevant, I believe. The original version from which I distilled this did not play any such trick.

You can reproduce this as follows:

  1. Download commit f2549d0 of the VST repository,
  2. Do "make -j7" (or whatever -j argument you like)
  3. In the last-built file, progs/verif_binary_heap.v, find the line near the end labeled
    (* UNCOMMENT THIS LINE TO HAVE Qed BLOW UP IN Coq 8.11.1 ... *)
    and uncomment the replace command.

  4. Notice that Qed now blows up. Memory usage doesn't blow up, just run time.

Coq Version 8.11.1

view this post on Zulip Coq Github Bot (May 20 2020 at 18:05):

Zimmi48 submitted PR Review for #12377 Adapt the documentation to the move from Gitter to Zulip.

view this post on Zulip Coq Github Bot (May 20 2020 at 18:05):

Zimmi48 created PR Review Comment on #12377 Adapt the documentation to the move from Gitter to Zulip.

Yep, we cannot decently bury it given the number of users, but we must have a consistent communication regarding our privileged platforms IMHO.

view this post on Zulip Coq Github Bot (May 20 2020 at 18:13):

ejgallego labeled Issue #12378 benign-looking 'replace' causes Qed to blow up:

Description of the problem

In Coq 8.11.1, a 'replace' command causes the Qed to blow up (I killed it after 1 hour), but without the 'replace', the Qed takes about 0.2 seconds.

That is: In my theorem, after 100 lines of nontrivial proof script (but the kind that is normally well within Coq's capacity), I come to this proof goal:

j, c : forall _ : environ, mpred
H7 : derives c j
______________________________________(1/1)
True

If I finish the proof with auto. Qed. then the Qed takes 0.22 seconds.
If I finish the proof with replace c with j in H7 by apply admit. auto. Qed. then the Qed takes more than an hour, if indeed it ever finishes.

The fact that I'm using a very generous Admitted lemma called admit is irrelevant, I believe. The original version from which I distilled this did not play any such trick.

You can reproduce this as follows:

  1. Download commit f2549d0 of the VST repository,
  2. Do "make -j7" (or whatever -j argument you like)
  3. In the last-built file, progs/verif_binary_heap.v, find the line near the end labeled
    (* UNCOMMENT THIS LINE TO HAVE Qed BLOW UP IN Coq 8.11.1 ... *)
    and uncomment the replace command.

  4. Notice that Qed now blows up. Memory usage doesn't blow up, just run time.

Coq Version 8.11.1

view this post on Zulip Coq Github Bot (May 20 2020 at 18:19):

jfehrle opened PR #12379 Omit voluminous Latex warnings from silence_latex to master:

Similar to https://github.com/coq/coq/pull/12195. The -q of that PR didn't make much difference and hid some messages useful for local work.

view this post on Zulip Coq Github Bot (May 20 2020 at 18:19):

jfehrle requested doc-maintainers for a review on PR #12379 Omit voluminous Latex warnings.

view this post on Zulip Coq Github Bot (May 20 2020 at 18:19):

cpitclaudel pushed 2 commits to branch master. Commits by Zimmi48 (1) and cpitclaudel (1).

view this post on Zulip Coq Github Bot (May 20 2020 at 18:19):

cpitclaudel merged PR #12377 Adapt the documentation to the move from Gitter to Zulip.

view this post on Zulip Coq Github Bot (May 20 2020 at 18:22):

jfehrle updated PR #12379 Omit voluminous Latex warnings from silence_latex to master:

Similar to https://github.com/coq/coq/pull/12195. The -q of that PR didn't make much difference and hid some messages useful for local work.

view this post on Zulip Coq Github Bot (May 20 2020 at 18:28):

cpitclaudel submitted PR Review for #12377 Adapt the documentation to the move from Gitter to Zulip.

view this post on Zulip Coq Github Bot (May 20 2020 at 18:28):

cpitclaudel created PR Review Comment on #12377 Adapt the documentation to the move from Gitter to Zulip.

I hadn't realized up to this point that discourse was now preferred.

view this post on Zulip Coq Github Bot (May 20 2020 at 18:29):

proux01 updated PR #12218 Numeral notations for non inductive types from numeral-notations-non-inductive to master:

This is a tentative implementation of the idea discussed in #12035

This is a draft PR due to the fact that it is still lacking some proofs and proper documentation.

Numeral Notation non_inductive via inductive using ...

The main idea is to use actual inductive types that map what you want to parse/print and just translate to (resp. from) the actual type from (resp. to) this inductive type after calling the parser (resp before the printer). One then just has to provide a mapping from globrefs of the actual type to constructors of the inductive type.

For instance, for reals, that looks something like

Inductive IZ :=
| IZpow_pos : Z -> positive -> IZ
| IZ0 : IZ
| IZpos : positive -> IZ
| IZneg : positive -> IZ.

Inductive IR :=
| IRZ : IZ -> IR
| IRQ : Q -> IR
| IRmult : IR -> IR -> IR
| IRdiv : IR -> IR -> IR.

[..]  (* define parser numeral_to_IR and printer IR_to_numeral *)

Numeral Notation R via IR
  using (IZR IRZ, Q2R IRQ, Rmult IRmult, Rdiv IRdiv,
         Z.pow_pos IZpow_pos, Z0 IZ0, Zpos IZpos, Zneg IZneg)
  numeral_to_IR IR_to_numeral : R_scope.

Two notations are provided as examples for Q and R.

Q

Previously rationals were all parsed as a pair numerator, denominator. This means 1.02 and 102e-2 were both parsed as 102 # 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is still parsed as a power of ten denominator but exponents are parsed as a product or division by Z.pow_pos. For instance, 1.02 is parsed as 102 # 100 whereas 102e-2 is parsed as (102 # 1) / (Z.pow_pos 10 2 # 1).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = (102 # 100) * (10 # 1) = 1020 # 100 and 10.2 = 102 # 10 no longer are.

A nice side effect is that exponents can no longer blow up during parsing. Previously 1e1_000_000 literally produced a numerator with a million digits, now it just yields (1 # 1) * (Z.pow_pos 10 1_000_000 # 1).

R

Previously real constants were parsed by an unproved OCaml code. The parser and printer are now implemented in Coq, which will enable a proof and hopefully make it easier to maintain / make evolve.

Previously reals were all parsed as an integer, an integer multiplied by a power of ten or an integer divided by a power of ten. This means 1.02 and 102e-2 were both parsed as 102 / 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is parsed as a rational and exponents are parsed as a product or division by a power of ten. For instance, 1.02 is parsed as Q2R (102 # 100) whereas 102e-2 is parsed as IZR 102 / IZR (Z.pow_pos 10 2).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = Q2R (102 # 100) * 10 and 10.2 = Q2R (102 # 10) no longer are.

TODO

~Depends from: #11948~

view this post on Zulip Coq Github Bot (May 20 2020 at 18:52):

jfehrle updated PR #12369 Handle conversion inconsistency between html and pdf for ids= and names= from fix_pdf_names to master:

Fixes #12361

view this post on Zulip Coq Github Bot (May 20 2020 at 19:18):

JasonGross updated PR #12316 Use pagination in fetching the number of reviews (assigned to SkySkimmer) from fix-12300 to master:

Fixes #12300

Note that I currently only paginate the API call for the number of
reviews, not the main API call, because (a) the main API call doesn't
seem subject to pagination (it returns a dict, not an array), and (b)
because fetching the total number of pages incurs an extra API call for
each one that we want to paginate, even if there is only one page. We
could work around (b) with a significantly more complicated
curl_paginate function which heuristically recognizes the end of the
header/beginning of the body, such as

curl_paginate() {
  # as per https://developer.github.com/v3/guides/traversing-with-pagination/#changing-the-number-of-items-received, GitHub will never give us more than 100
  url="$1?per_page=100"
  # We need to process the header to get the pagination.  We have two
  # options:
  #
  # 1. We can make an extra API call at the beginning to get the total
  #    number of pages, search for a rel="last" link, and then loop
  #    over all the pages.
  #
  # 2. We can ask for the header info with every single curl request,
  #    search for a rel="next" link to follow to the next page, and
  #    then parse out the body from the header.
  #
  # Although (1) is simpler, we choose to do (2) to save an extra API
  # call per invocation of curl.
  while [ ! -z "${url}" ]; do
    response="$(curl -si "${url}")"
    # we search for something like 'link: <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="next", <https://api.github.com/repositories/1377159/pulls/12129/reviews?page=2>; rel="last"' and take the first 'next' url
    url="$(echo "${response}" | grep -m 1 -io '^link: .*>; rel="next"' | grep -o '<[^>]*>; rel="next"' | grep -o '<[^>]*>' | sed s'/[<>]//g')"
    echo "${response}" |
      {
        is_header="yes"
        while read line; do
          if [ "${is_header}" == "yes" ]; then
            if echo "${line}" | grep -q '^\s*[\[{]'; then # we treat lines beginning with [ or { as the beginning of the response body
              is_header="no"
              echo "${line}"
            fi
          else
            echo "${line}"
          fi
        done
      }
  done
}

Kind: bug fix / infrastructure.

view this post on Zulip Coq Github Bot (May 20 2020 at 19:24):

JasonGross updated PR #12368 Print a newline at the end of timing tables (assigned to SkySkimmer) from fix-missing-newline-time-file-maker to master:

This, for example, improves the CI display, so that $ echo 'end:coq.test' does not appear on the same line as the end of the
timing table.

Kind: bug fix

view this post on Zulip Coq Github Bot (May 20 2020 at 19:24):

JasonGross submitted PR Review for #12368 Print a newline at the end of timing tables.

view this post on Zulip Coq Github Bot (May 20 2020 at 19:24):

JasonGross created PR Review Comment on #12368 Print a newline at the end of timing tables:

Should be fixed now

view this post on Zulip Coq Github Bot (May 20 2020 at 19:33):

jfehrle edited PR #12369 Show correct index entries in pdf from fix_pdf_names to master:

Fixes #12361

view this post on Zulip Coq Github Bot (May 20 2020 at 19:33):

jfehrle requested doc-maintainers for a review on PR #12369 Show correct index entries in pdf.

view this post on Zulip Coq Github Bot (May 20 2020 at 19:40):

SkySkimmer submitted PR Review for #12368 Print a newline at the end of timing tables.

view this post on Zulip Coq Github Bot (May 20 2020 at 19:40):

SkySkimmer created PR Review Comment on #12368 Print a newline at the end of timing tables:

So what was going on?

view this post on Zulip Coq Github Bot (May 20 2020 at 20:40):

JasonGross submitted PR Review for #12368 Print a newline at the end of timing tables.

view this post on Zulip Coq Github Bot (May 20 2020 at 20:40):

JasonGross created PR Review Comment on #12368 Print a newline at the end of timing tables:

I believe this test-suite-test was insensitive to lack of trailing newlines, and I was picking up the wrong version of the script when regenerating it, I believe

view this post on Zulip Coq Github Bot (May 21 2020 at 03:09):

cpitclaudel opened PR #12380 Fix #12361 (indexing issues in the PDF) from fix-12361 to master:

Kind: infrastructure.

Follow up to https://github.com/coq/coq/issues/12361.

view this post on Zulip Coq Github Bot (May 21 2020 at 03:09):

cpitclaudel requested Zimmi48, jfehrle and doc-maintainers for a review on PR #12380 Fix #12361 (indexing issues in the PDF).

view this post on Zulip Coq Github Bot (May 21 2020 at 03:09):

cpitclaudel requested Zimmi48, jfehrle and doc-maintainers for a review on PR #12380 Fix #12361 (indexing issues in the PDF).

view this post on Zulip Coq Github Bot (May 21 2020 at 03:09):

cpitclaudel requested Zimmi48, jfehrle and doc-maintainers for a review on PR #12380 Fix #12361 (indexing issues in the PDF).

view this post on Zulip Coq Github Bot (May 21 2020 at 05:26):

jfehrle submitted PR Review for #12380 Fix #12361 (indexing issues in the PDF)

view this post on Zulip Coq Github Bot (May 21 2020 at 05:26):

jfehrle submitted PR Review for #12380 Fix #12361 (indexing issues in the PDF)

view this post on Zulip Coq Github Bot (May 21 2020 at 05:26):

jfehrle created PR Review Comment on #12380 Fix #12361 (indexing issues in the PDF)

We didn't want to repeat the definition 10 times here--that would look mighty strange. I suggest removing the parenthesized comment. We're not bound by tradition, are we?

![image](https://user-images.githubusercontent.com/1253341/82524776-a6ce9980-9ae4-11ea-9fc6-6f1d697af1d4.png)

view this post on Zulip Coq Github Bot (May 21 2020 at 05:26):

jfehrle created PR Review Comment on #12380 Fix #12361 (indexing issues in the PDF)

        """Attach a link target to `signode` and index entries for `names`.

view this post on Zulip Coq Github Bot (May 21 2020 at 05:27):

jfehrle submitted PR Review for #12380 Fix #12361 (indexing issues in the PDF)

view this post on Zulip Coq Github Bot (May 21 2020 at 10:21):

Mbodin opened Issue #12381 Coq allows one to try to prove forall (P : SProp) (x y : P), x = y, despite being ill-typed.

Description of the problem

I found this line in a Coq project: https://gitlab.inria.fr/kmaillar/dijkstra-monads-for-all/-/blob/master/theories/sprop/SPropBase.v#L262
I don’t know much of SProp, but as I didn’t see this issue reported here, I wanted to make sure that this issue is referenced here too.

Here is a minimal example:

(* -*- coq-prog-args: ("-allow-sprop"); -*- *)

Goal forall (P : SProp) (x y : P), x = y.
Proof.
admit.
Admitted. (* fails *)

Coq Version

Coq 8.10.1.

view this post on Zulip Coq Github Bot (May 21 2020 at 10:28):

SkySkimmer closed Issue #12381 Coq allows one to try to prove forall (P : SProp) (x y : P), x = y, despite being ill-typed.

Description of the problem

I found this line in a Coq project: https://gitlab.inria.fr/kmaillar/dijkstra-monads-for-all/-/blob/master/theories/sprop/SPropBase.v#L262
I don’t know much of SProp, but as I didn’t see this issue reported here, I wanted to make sure that this issue is referenced here too.

Here is a minimal example:

(* -*- coq-prog-args: ("-allow-sprop"); -*- *)

Goal forall (P : SProp) (x y : P), x = y.
Proof.
admit.
Admitted. (* fails *)

Coq Version

Coq 8.10.1.

view this post on Zulip Coq Github Bot (May 21 2020 at 12:32):

ejgallego labeled Issue #12382 [zulip] Please move notifications to their own stream.

The notifications topics currently live in the "Coq dev" stream; IMHO they would be better in their own stream "Github notifications", the current setup:

view this post on Zulip Coq Github Bot (May 21 2020 at 12:32):

ejgallego opened Issue #12382 [zulip] Please move notifications to their own stream.

The notifications topics currently live in the "Coq dev" stream; IMHO they would be better in their own stream "Github notifications", the current setup:

view this post on Zulip Coq Github Bot (May 21 2020 at 12:47):

SkySkimmer pushed 4 commits to branch master. Commits by JasonGross (3) and SkySkimmer (1).

view this post on Zulip Coq Github Bot (May 21 2020 at 12:47):

SkySkimmer closed Issue #12300 merge-pr doesn't understand pagination:

For instance with #12129 it sees no APPROVED review because it's on page 2 (https://api.github.com/repos/coq/coq/pulls/12129/reviews?page=2)

Not sure if ignoring pagination can cause issues with the main api call.

view this post on Zulip Coq Github Bot (May 21 2020 at 12:47):

SkySkimmer merged PR #12316 Use pagination in fetching the number of reviews.

view this post on Zulip Coq Github Bot (May 21 2020 at 12:47):

coqbot milestoned Issue #12300 merge-pr doesn't understand pagination:

For instance with #12129 it sees no APPROVED review because it's on page 2 (https://api.github.com/repos/coq/coq/pulls/12129/reviews?page=2)

Not sure if ignoring pagination can cause issues with the main api call.

view this post on Zulip Coq Github Bot (May 21 2020 at 12:47):

SkySkimmer pushed 2 commits to branch master. Commits by SkySkimmer (1) and ejgallego (1).

view this post on Zulip Coq Github Bot (May 21 2020 at 12:47):

SkySkimmer closed Issue #12351 Redirect ignores Set Printing Width:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Axiom foo : forall a b c d e f g h i j k l m n o p q r s t u v w x y z : Set, a->b->c->d->e->f->g->h->i->j->k->l->m->n->o->p->q->r->s->t->u->v->w->x->y->z.
Set Printing Width 10000.
Print Assumptions foo.
(* Axioms:
foo : forall a b c d e f g h i j k l m n o p q r s t u v w x y z : Set, a -> b -> c -> d -> e -> f -> g -> h -> i -> j -> k -> l -> m -> n -> o -> p -> q -> r -> s -> \
t -> u -> v -> w -> x -> y -> z *)
Redirect "foo" Print Assumptions foo.
(* Axioms:
foo : forall a b c d e f g h i j k l m n o p q r s t u v w x y z : Set,
      a ->
      b ->
      c ->
      d ->
      e ->
      f ->
      g ->
      h ->
      i ->
      j ->
      k ->
      l -> m -> n -> o -> p -> q -> r -> s -> t -> u -> v -> w -> x -> y -> z
*)

This makes it much more annoying to make fiat-crypto compatible with #11980 in a backwards-compatible way.

Coq Version

8.11.1

view this post on Zulip Coq Github Bot (May 21 2020 at 12:48):

SkySkimmer merged PR #12358 [topfmt] Set formatter + flush fix.

view this post on Zulip Coq Github Bot (May 21 2020 at 12:48):

coqbot milestoned Issue #12351 Redirect ignores Set Printing Width:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Axiom foo : forall a b c d e f g h i j k l m n o p q r s t u v w x y z : Set, a->b->c->d->e->f->g->h->i->j->k->l->m->n->o->p->q->r->s->t->u->v->w->x->y->z.
Set Printing Width 10000.
Print Assumptions foo.
(* Axioms:
foo : forall a b c d e f g h i j k l m n o p q r s t u v w x y z : Set, a -> b -> c -> d -> e -> f -> g -> h -> i -> j -> k -> l -> m -> n -> o -> p -> q -> r -> s -> \
t -> u -> v -> w -> x -> y -> z *)
Redirect "foo" Print Assumptions foo.
(* Axioms:
foo : forall a b c d e f g h i j k l m n o p q r s t u v w x y z : Set,
      a ->
      b ->
      c ->
      d ->
      e ->
      f ->
      g ->
      h ->
      i ->
      j ->
      k ->
      l -> m -> n -> o -> p -> q -> r -> s -> t -> u -> v -> w -> x -> y -> z
*)

This makes it much more annoying to make fiat-crypto compatible with #11980 in a backwards-compatible way.

Coq Version

8.11.1

view this post on Zulip Coq Github Bot (May 21 2020 at 12:48):

SkySkimmer pushed 3 commits to branch master. Commits by SkySkimmer (1), Zimmi48 (1) and ejgallego (1).

view this post on Zulip Coq Github Bot (May 21 2020 at 12:48):

SkySkimmer merged PR #12364 [ci] [docker] Bump ocamlformat and dune.

view this post on Zulip Coq Github Bot (May 21 2020 at 12:49):

SkySkimmer pushed 2 commits to branch master. Commits by JasonGross (1) and SkySkimmer (1).

view this post on Zulip Coq Github Bot (May 21 2020 at 12:49):

SkySkimmer merged PR #12368 Print a newline at the end of timing tables.

view this post on Zulip Coq Github Bot (May 21 2020 at 12:51):

SkySkimmer pushed 5 commits to branch master. Commits by ejgallego (4) and SkySkimmer (1).

view this post on Zulip Coq Github Bot (May 21 2020 at 12:51):

SkySkimmer merged PR #12371 [obligations] Minor refactoring.

view this post on Zulip Coq Github Bot (May 21 2020 at 13:34):

Janno opened PR #12383 [Pretyping] Trigger CS search during pretyping of lambdas and applications from janno/cs_fun_nocast to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

This PR allows the pretyper to look for suitable canonical instances to make the following typing problems succeed (which I consider to be dual to each other):

f : key ?c ⊢ f x : _

and

(fun _ : _ => _) : key ?c

I am actually calling unification to trigger the search because I couldn't figure out how to use the result of lookup_canonical_projection. There will surely be a cost to this. However, I did put in a check to see if there is a Prod_cs instance for key. If there isn't, unification is never called. This should limit the impact.

Unfortunately, there is also an unnecessary call to whd_all in pretype_lambda. This could be removed with some refactoring of split_tycon, where the same reduction is already performed. (One could also imagine that split_tycon would actually be a better place to trigger the CS search but that seemed wrong to me.)

I am marking this a draft because a) the code needs cleaning up, b) I am not convinced that unification is the best way to trigger CS here, and c) there might be metatheoretical implications to this change that I am not aware of.

Depends on: #12349 (because I didn't know how to create the evars for _ -> _, i.e. how to make sure the 2nd _ doesn't depend on the first.)

<!-- Keep what applies -->
Kind: bug fix & feature.

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #11189

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 21 2020 at 13:45):

SkySkimmer updated PR #12383 [Pretyping] Trigger CS search during pretyping of lambdas and applications from janno/cs_fun_nocast to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

This PR allows the pretyper to look for suitable canonical instances to make the following typing problems succeed (which I consider to be dual to each other):

f : key ?c ⊢ f x : _

and

(fun _ : _ => _) : key ?c

I am actually calling unification to trigger the search because I couldn't figure out how to use the result of lookup_canonical_projection. There will surely be a cost to this. However, I did put in a check to see if there is a Prod_cs instance for key. If there isn't, unification is never called. This should limit the impact.

Unfortunately, there is also an unnecessary call to whd_all in pretype_lambda. This could be removed with some refactoring of split_tycon, where the same reduction is already performed. (One could also imagine that split_tycon would actually be a better place to trigger the CS search but that seemed wrong to me.)

I am marking this a draft because a) the code needs cleaning up, b) I am not convinced that unification is the best way to trigger CS here, and c) there might be metatheoretical implications to this change that I am not aware of.

Depends on: #12349 (because I didn't know how to create the evars for _ -> _, i.e. how to make sure the 2nd _ doesn't depend on the first.)

<!-- Keep what applies -->
Kind: bug fix & feature.

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #11189

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 21 2020 at 13:49):

SkySkimmer submitted PR Review for #12383 [Pretyping] Trigger CS search during pretyping of lambdas and applications.

view this post on Zulip Coq Github Bot (May 21 2020 at 13:49):

SkySkimmer created PR Review Comment on #12383 [Pretyping] Trigger CS search during pretyping of lambdas and applications:

mkConst (non U) is certainly incorrect
You may be able to get universes out of decompose_reduced_canonical_projection, it should be the same instance as the instance for the inductive type.

view this post on Zulip Coq Github Bot (May 21 2020 at 13:56):

Janno updated PR #12383 [Pretyping] Trigger CS search during pretyping of lambdas and applications from janno/cs_fun_nocast to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

This PR allows the pretyper to look for suitable canonical instances to make the following typing problems succeed (which I consider to be dual to each other):

f : key ?c ⊢ f x : _

and

(fun _ : _ => _) : key ?c

I am actually calling unification to trigger the search because I couldn't figure out how to use the result of lookup_canonical_projection. There will surely be a cost to this. However, I did put in a check to see if there is a Prod_cs instance for key. If there isn't, unification is never called. This should limit the impact.

Unfortunately, there is also an unnecessary call to whd_all in pretype_lambda. This could be removed with some refactoring of split_tycon, where the same reduction is already performed. (One could also imagine that split_tycon would actually be a better place to trigger the CS search but that seemed wrong to me.)

I am marking this a draft because a) the code needs cleaning up, b) I am not convinced that unification is the best way to trigger CS here, and c) there might be metatheoretical implications to this change that I am not aware of.

Depends on: #12349 (because I didn't know how to create the evars for _ -> _, i.e. how to make sure the 2nd _ doesn't depend on the first.)

<!-- Keep what applies -->
Kind: bug fix & feature.

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #11189

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 21 2020 at 13:59):

Janno updated PR #12383 [Pretyping] Trigger CS search during pretyping of lambdas and applications from janno/cs_fun_nocast to master:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

This PR allows the pretyper to look for suitable canonical instances to make the following typing problems succeed (which I consider to be dual to each other):

f : key ?c ⊢ f x : _

and

(fun _ : _ => _) : key ?c

I am actually calling unification to trigger the search because I couldn't figure out how to use the result of lookup_canonical_projection. There will surely be a cost to this. However, I did put in a check to see if there is a Prod_cs instance for key. If there isn't, unification is never called. This should limit the impact.

Unfortunately, there is also an unnecessary call to whd_all in pretype_lambda. This could be removed with some refactoring of split_tycon, where the same reduction is already performed. (One could also imagine that split_tycon would actually be a better place to trigger the CS search but that seemed wrong to me.)

I am marking this a draft because a) the code needs cleaning up, b) I am not convinced that unification is the best way to trigger CS here, and c) there might be metatheoretical implications to this change that I am not aware of.

Depends on: #12349 (because I didn't know how to create the evars for _ -> _, i.e. how to make sure the 2nd _ doesn't depend on the first.)

<!-- Keep what applies -->
Kind: bug fix & feature.

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #11189

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 21 2020 at 13:59):

Janno submitted PR Review for #12383 [Pretyping] Trigger CS search during pretyping of lambdas and applications.

view this post on Zulip Coq Github Bot (May 21 2020 at 13:59):

Janno created PR Review Comment on #12383 [Pretyping] Trigger CS search during pretyping of lambdas and applications:

Should be fixed now.

view this post on Zulip Coq Github Bot (May 21 2020 at 14:11):

ejgallego updated PR #12372 [declare] Refactor constant information into a record. from proof+info to master:

This improves the interface, and allows even more sealing of the API.

This is yet work in progress.

view this post on Zulip Coq Github Bot (May 21 2020 at 15:27):

Zimmi48 assigned Issue #12382 [zulip] Please move notifications to their own stream. (assigned to Zimmi48):

The notifications topics currently live in the "Coq dev" stream; IMHO they would be better in their own stream "Github notifications", the current setup:

view this post on Zulip Coq Github Bot (May 21 2020 at 16:02):

MSoegtropIMC updated PR #12186 CReal: changed epsilon for modulus of convergence from 1/n to 1/2^n from creal-new-modulus to master:

This PR changes the epsilon in the definition of the modulus of convergence for CReal from 1/n to 1/2^n. This avoids the issue that in practical high precision computations, even as binary integer n would be quite large (say 2^1000000), although quadratically convergent algorithms might need only a few 10 iterations to reach such a precision.

This is work in progress (right now I just did the main file ConstructiveCauchyReals.v).

@VincentSe : some things I think I should change:

view this post on Zulip Coq Github Bot (May 21 2020 at 19:15):

JasonGross edited Issue #12378 'simpl' can easily cause Qed to blow up:

Description of the problem

In Coq 8.11.1, a 'replace' command causes the Qed to blow up (I killed it after 1 hour), but without the 'replace', the Qed takes about 0.2 seconds.

That is: In my theorem, after 100 lines of nontrivial proof script (but the kind that is normally well within Coq's capacity), I come to this proof goal:

j, c : forall _ : environ, mpred
H7 : derives c j
______________________________________(1/1)
True

If I finish the proof with auto. Qed. then the Qed takes 0.22 seconds.
If I finish the proof with replace c with j in H7 by apply admit. auto. Qed. then the Qed takes more than an hour, if indeed it ever finishes.

The fact that I'm using a very generous Admitted lemma called admit is irrelevant, I believe. The original version from which I distilled this did not play any such trick.

You can reproduce this as follows:

  1. Download commit f2549d0 of the VST repository,
  2. Do "make -j7" (or whatever -j argument you like)
  3. In the last-built file, progs/verif_binary_heap.v, find the line near the end labeled
    (* UNCOMMENT THIS LINE TO HAVE Qed BLOW UP IN Coq 8.11.1 ... *)
    and uncomment the replace command.

  4. Notice that Qed now blows up. Memory usage doesn't blow up, just run time.

Coq Version 8.11.1

view this post on Zulip Coq Github Bot (May 21 2020 at 19:44):

JasonGross opened Issue #12384 Request: Configurable native_compute optimization flags:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I have a case (https://github.com/mit-plv/fiat-crypto/pull/803#issuecomment-632291776) where vm_compute takes about 240 seconds, native_compute takes 31.29 secs (31.081u,0.114s) (of which 31.08720 are spent in evaluation and 0.02058 are spent in reification. This is less than half the size of the test-case I'd like to be running. I'd like to have the option to specify more aggressive optimization flags (such as flambda (is this -funbox-closures?) and -O3 rather than -Oclassic), forcing a recompilation of the dependencies of my term on the fly if need be. I'd be willing to wait an extra 10--15 seconds of compilation time if it sped up my computation by enough here. (This obviously isn't a good trade-off in general, but it might be here.)

On the other hand, when I extract this code, I see basically no difference, neither in compile-time nor run-time, between -Oclassic vs -O3 -unbox-closures.

cc @maximedenes

Coq Version

8.11.1

view this post on Zulip Coq Github Bot (May 21 2020 at 19:44):

JasonGross labeled Issue #12384 Request: Configurable native_compute optimization flags:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I have a case (https://github.com/mit-plv/fiat-crypto/pull/803#issuecomment-632291776) where vm_compute takes about 240 seconds, native_compute takes 31.29 secs (31.081u,0.114s) (of which 31.08720 are spent in evaluation and 0.02058 are spent in reification. This is less than half the size of the test-case I'd like to be running. I'd like to have the option to specify more aggressive optimization flags (such as flambda (is this -funbox-closures?) and -O3 rather than -Oclassic), forcing a recompilation of the dependencies of my term on the fly if need be. I'd be willing to wait an extra 10--15 seconds of compilation time if it sped up my computation by enough here. (This obviously isn't a good trade-off in general, but it might be here.)

On the other hand, when I extract this code, I see basically no difference, neither in compile-time nor run-time, between -Oclassic vs -O3 -unbox-closures.

cc @maximedenes

Coq Version

8.11.1

view this post on Zulip Coq Github Bot (May 21 2020 at 20:14):

JasonGross labeled Issue #12385 Notation .. does not recognize printing boxes well enough:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Require Import Coq.Lists.List.
Notation "[ x ; y ; .. ; z ]" :=  (cons x (cons y .. (cons z nil) ..)) (format "'[hv ' [ '[' x ']' ;  '/' '[' y ']' ;  '/' .. ;  '/' '[' z ']' ] ']'") : list_scope.
(* Error:
The format is not the same on the right- and left-hand sides of the special token "..". *)

I think this is a bug, but maybe @herbelin will point out something I'm missing.

Coq Version

8.11.1

view this post on Zulip Coq Github Bot (May 21 2020 at 20:14):

JasonGross opened Issue #12385 Notation .. does not recognize printing boxes well enough:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Require Import Coq.Lists.List.
Notation "[ x ; y ; .. ; z ]" :=  (cons x (cons y .. (cons z nil) ..)) (format "'[hv ' [ '[' x ']' ;  '/' '[' y ']' ;  '/' .. ;  '/' '[' z ']' ] ']'") : list_scope.
(* Error:
The format is not the same on the right- and left-hand sides of the special token "..". *)

I think this is a bug, but maybe @herbelin will point out something I'm missing.

Coq Version

8.11.1

view this post on Zulip Notification Bot (May 21 2020 at 20:14):

This topic was moved here from #Coq devs & plugin devs > Github Noisy Notifications by Théo Zimmermann

view this post on Zulip Coq Github Bot (May 21 2020 at 20:19):

Zimmi48 closed Issue #12382 [zulip] Please move notifications to their own stream. (assigned to Zimmi48):

The notifications topics currently live in the "Coq dev" stream; IMHO they would be better in their own stream "Github notifications", the current setup:

view this post on Zulip Coq Github Bot (May 21 2020 at 21:49):

herbelin closed Issue #12385 Notation .. does not recognize printing boxes well enough:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Require Import Coq.Lists.List.
Notation "[ x ; y ; .. ; z ]" :=  (cons x (cons y .. (cons z nil) ..)) (format "'[hv ' [ '[' x ']' ;  '/' '[' y ']' ;  '/' .. ;  '/' '[' z ']' ] ']'") : list_scope.
(* Error:
The format is not the same on the right- and left-hand sides of the special token "..". *)

I think this is a bug, but maybe @herbelin will point out something I'm missing.

Coq Version

8.11.1

view this post on Zulip Coq Github Bot (May 21 2020 at 21:51):

JasonGross labeled Issue #12384 Request: Configurable native_compute optimization flags:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I have a case (https://github.com/mit-plv/fiat-crypto/pull/803#issuecomment-632291776) where vm_compute takes about 240 seconds, native_compute takes 31.29 secs (31.081u,0.114s) (of which 31.08720 are spent in evaluation and 0.02058 are spent in reification. This is less than half the size of the test-case I'd like to be running. I'd like to have the option to specify more aggressive optimization flags (such as flambda (is this -funbox-closures?) and -O3 rather than -Oclassic), forcing a recompilation of the dependencies of my term on the fly if need be. I'd be willing to wait an extra 10--15 seconds of compilation time if it sped up my computation by enough here. (This obviously isn't a good trade-off in general, but it might be here.)

On the other hand, when I extract this code, I see basically no difference, neither in compile-time nor run-time, between -Oclassic vs -O3 -unbox-closures.

cc @maximedenes

Coq Version

8.11.1

view this post on Zulip Coq Github Bot (May 21 2020 at 21:51):

JasonGross labeled Issue #12384 Request: Configurable native_compute optimization flags:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I have a case (https://github.com/mit-plv/fiat-crypto/pull/803#issuecomment-632291776) where vm_compute takes about 240 seconds, native_compute takes 31.29 secs (31.081u,0.114s) (of which 31.08720 are spent in evaluation and 0.02058 are spent in reification. This is less than half the size of the test-case I'd like to be running. I'd like to have the option to specify more aggressive optimization flags (such as flambda (is this -funbox-closures?) and -O3 rather than -Oclassic), forcing a recompilation of the dependencies of my term on the fly if need be. I'd be willing to wait an extra 10--15 seconds of compilation time if it sped up my computation by enough here. (This obviously isn't a good trade-off in general, but it might be here.)

On the other hand, when I extract this code, I see basically no difference, neither in compile-time nor run-time, between -Oclassic vs -O3 -unbox-closures.

cc @maximedenes

Coq Version

8.11.1

view this post on Zulip Coq Github Bot (May 21 2020 at 21:53):

JasonGross opened Issue #12386 dev/tools/make-changelog.sh should automatically handle bugs fixed by the PR:

I'd like dev/tools/make-changelog.sh to also ask me if the PR fixes any bugs (say, a space-separated list of numbers), and it should automatically generate the "Fixes" part of the changelog as well

view this post on Zulip Coq Github Bot (May 21 2020 at 21:53):

JasonGross labeled Issue #12386 dev/tools/make-changelog.sh should automatically handle bugs fixed by the PR:

I'd like dev/tools/make-changelog.sh to also ask me if the PR fixes any bugs (say, a space-separated list of numbers), and it should automatically generate the "Fixes" part of the changelog as well

view this post on Zulip Coq Github Bot (May 21 2020 at 21:53):

JasonGross labeled Issue #12386 dev/tools/make-changelog.sh should automatically handle bugs fixed by the PR:

I'd like dev/tools/make-changelog.sh to also ask me if the PR fixes any bugs (say, a space-separated list of numbers), and it should automatically generate the "Fixes" part of the changelog as well

view this post on Zulip Coq Github Bot (May 21 2020 at 21:55):

JasonGross opened Issue #12387 make print-pretty-timed-diff will raise a python exception if either "before" or "after" has no files (assigned to JasonGross):

Traceback (most recent call last):
  File "/home/jgross/Documents/repos/coq/tools/make-both-time-files.py", line 16, in <module>
    table = make_diff_table_string(left_dict, right_dict, sort_by=args.sort_by, include_mem=args.include_mem, sort_by_mem=args.sort_by_mem)
  File "/home/jgross/Documents/repos/coq/tools/TimeFileMaker.py", line 391, in make_diff_table_string
    right_peak = max(v.get(MEM_KEY, 0) for v in right_dict.values())
ValueError: max() arg is an empty sequence

view this post on Zulip Coq Github Bot (May 21 2020 at 21:55):

JasonGross labeled Issue #12387 make print-pretty-timed-diff will raise a python exception if either "before" or "after" has no files (assigned to JasonGross):

Traceback (most recent call last):
  File "/home/jgross/Documents/repos/coq/tools/make-both-time-files.py", line 16, in <module>
    table = make_diff_table_string(left_dict, right_dict, sort_by=args.sort_by, include_mem=args.include_mem, sort_by_mem=args.sort_by_mem)
  File "/home/jgross/Documents/repos/coq/tools/TimeFileMaker.py", line 391, in make_diff_table_string
    right_peak = max(v.get(MEM_KEY, 0) for v in right_dict.values())
ValueError: max() arg is an empty sequence

view this post on Zulip Coq Github Bot (May 21 2020 at 21:55):

JasonGross assigned Issue #12387 make print-pretty-timed-diff will raise a python exception if either "before" or "after" has no files (assigned to JasonGross):

Traceback (most recent call last):
  File "/home/jgross/Documents/repos/coq/tools/make-both-time-files.py", line 16, in <module>
    table = make_diff_table_string(left_dict, right_dict, sort_by=args.sort_by, include_mem=args.include_mem, sort_by_mem=args.sort_by_mem)
  File "/home/jgross/Documents/repos/coq/tools/TimeFileMaker.py", line 391, in make_diff_table_string
    right_peak = max(v.get(MEM_KEY, 0) for v in right_dict.values())
ValueError: max() arg is an empty sequence

view this post on Zulip Coq Github Bot (May 21 2020 at 21:55):

JasonGross labeled Issue #12387 make print-pretty-timed-diff will raise a python exception if either "before" or "after" has no files (assigned to JasonGross):

Traceback (most recent call last):
  File "/home/jgross/Documents/repos/coq/tools/make-both-time-files.py", line 16, in <module>
    table = make_diff_table_string(left_dict, right_dict, sort_by=args.sort_by, include_mem=args.include_mem, sort_by_mem=args.sort_by_mem)
  File "/home/jgross/Documents/repos/coq/tools/TimeFileMaker.py", line 391, in make_diff_table_string
    right_peak = max(v.get(MEM_KEY, 0) for v in right_dict.values())
ValueError: max() arg is an empty sequence

view this post on Zulip Coq Github Bot (May 21 2020 at 22:01):

JasonGross opened PR #12388 Fix an uncaught python exception in timing from fix-timing-diff-0s to master:

Previously, when either the 'before' or 'after' had no files, we'd get
an uncaught exception:

Traceback (most recent call last):
  File "/home/jgross/Documents/repos/coq/tools/make-both-time-files.py", line 16, in <module>
    table = make_diff_table_string(left_dict, right_dict, sort_by=args.sort_by, include_mem=args.include_mem, sort_by_mem=args.sort_by_mem)
  File "/home/jgross/Documents/repos/coq/tools/TimeFileMaker.py", line 391, in make_diff_table_string
    right_peak = max(v.get(MEM_KEY, 0) for v in right_dict.values())
ValueError: max() arg is an empty sequence

Fixes #12387

view this post on Zulip Coq Github Bot (May 21 2020 at 22:01):

JasonGross milestoned Issue #12388 Fix an uncaught python exception in timing:

Previously, when either the 'before' or 'after' had no files, we'd get
an uncaught exception:

Traceback (most recent call last):
  File "/home/jgross/Documents/repos/coq/tools/make-both-time-files.py", line 16, in <module>
    table = make_diff_table_string(left_dict, right_dict, sort_by=args.sort_by, include_mem=args.include_mem, sort_by_mem=args.sort_by_mem)
  File "/home/jgross/Documents/repos/coq/tools/TimeFileMaker.py", line 391, in make_diff_table_string
    right_peak = max(v.get(MEM_KEY, 0) for v in right_dict.values())
ValueError: max() arg is an empty sequence

Fixes #12387

view this post on Zulip Coq Github Bot (May 21 2020 at 22:01):

JasonGross requested coq-makefile-maintainers for a review on PR #12388 Fix an uncaught python exception in timing.

view this post on Zulip Coq Github Bot (May 21 2020 at 22:19):

ejgallego pushed 2 commits to branch v8.12. Commits by Zimmi48 (1) and ejgallego (1).

view this post on Zulip Coq Github Bot (May 21 2020 at 22:19):

ejgallego merged PR #12355 [8.12] Use pinned commits in dev/ci/ci-user-overlays.sh.

view this post on Zulip Coq Github Bot (May 22 2020 at 01:18):

ejgallego updated PR #12357 [declare] Remove some unused fix_exn from proof+no_fix_exn to master:

In the current proof save path, the kernel can raise an exception when
checking a proof wrapped into a future.

However, in this case, the future itself will "fix" the produced
exception, with the mandatory handler set at the future's creation
time.

Thus, there is no need for the declare layer to mess with exceptions
anymore, if my logic is correct. Note that the fix_exn parameter to
the Declare API was not used anymore.

This undoes 77cf18eb844b45776b2ec67be9f71e8dd4ca002c which comes from
pre-github times, so unfortunately I didn't have access to the
discussion.

We need to be careful in perform_buildp as to catch the Qed error
and properly notify the STM about it with State.exn_on; this was
previously done by the declare layer using a hack [grabbing internal
state of the future, that the future itself was not using as it was
already forced], but we now do it in the caller in a more principled
way.

This has been tested in the case that tactics succeed but Qed fails
asynchronously.

view this post on Zulip Coq Github Bot (May 22 2020 at 03:56):

pi8027 created PR Review Comment on #11906 [micromega] native support for boolean operators:

Sure. Actually what I saw in the documentation was Show Zify ... commands.

view this post on Zulip Coq Github Bot (May 22 2020 at 03:56):

pi8027 submitted PR Review for #11906 [micromega] native support for boolean operators.

view this post on Zulip Coq Github Bot (May 22 2020 at 09:14):

pi8027 submitted PR Review for #11906 [micromega] native support for boolean operators.

view this post on Zulip Coq Github Bot (May 22 2020 at 09:57):

ppedrot assigned PR #12344 Cleanup noisy prefixes to ppedrot.

view this post on Zulip Coq Github Bot (May 22 2020 at 09:57):

ppedrot milestoned Issue #12344 Cleanup noisy prefixes (assigned to ppedrot):

These bug me every time I look at them, they're not accessible outside section.ml / ustate.ml so there's no ambiguity to resolve.

view this post on Zulip Coq Github Bot (May 22 2020 at 09:59):

ppedrot pushed 2 commits to branch master. Commits by ppedrot (1) and proux01 (1).

view this post on Zulip Coq Github Bot (May 22 2020 at 10:00):

ppedrot merged PR #11986 [primitive floats] Add low level printing.

view this post on Zulip Coq Github Bot (May 22 2020 at 10:04):

ppedrot pushed 4 commits to branch master. Commits by herbelin (3) and ppedrot (1).

view this post on Zulip Coq Github Bot (May 22 2020 at 10:04):

ppedrot closed Issue #12233 "Show Proof" raises "Not_found" anomaly:

Adding "Show Proof" after the line + intuition. in theorem unrestricted_minimization_entails_excluded_middle in ClassicalFacts.v generates a Not_found anomaly.

I discovered this using a modified coqc that automatically applies a Show Proof after every tactic, then verified the bug in the official release. You get the same error on the following lines up to the Qed, but only in this proof in this library file. Nowhere else.

Coq Version 8.11.0

view this post on Zulip Coq Github Bot (May 22 2020 at 10:04):

ppedrot merged PR #12295 Fixes #12233: printing environment corrupted with eta-expansion of "match" branches.

view this post on Zulip Coq Github Bot (May 22 2020 at 10:05):

coqbot milestoned Issue #12233 "Show Proof" raises "Not_found" anomaly:

Adding "Show Proof" after the line + intuition. in theorem unrestricted_minimization_entails_excluded_middle in ClassicalFacts.v generates a Not_found anomaly.

I discovered this using a modified coqc that automatically applies a Show Proof after every tactic, then verified the bug in the official release. You get the same error on the following lines up to the Qed, but only in this proof in this library file. Nowhere else.

Coq Version 8.11.0

view this post on Zulip Coq Github Bot (May 22 2020 at 10:05):

ppedrot submitted PR Review for #12076 [coqchk] Fix #5030 (coqchk reports names from opaque modules as axioms)

view this post on Zulip Coq Github Bot (May 22 2020 at 10:06):

Mbodin opened PR #12389 Small coq_makefile improvement. from coq_makefile to master:

Kind: feature.

Relates to #7740 and #7722.

The behaviour of coq_makefile regarding DESTDIR is somehow confusing (as seen in the related bug reports above). The “usual” set-up in Linux seems to be:

The COQMF_WINDRIVE parts feels like a hack and is currently undocumented. This PR provides an alternative way (without breaking the previous way):

Being able to set up the installation directory is especially important when using programs like esy, in which different Coq installation can be shared among repositories: esy installs Coq libraries into their own directory, relying on the COQPATH mechanism to link everything back together. By forcing the installation to ${COQLIB}/user-contrib, coq_makefile is installing files in a shared folder, which breaks its invariants required for replication.

view this post on Zulip Coq Github Bot (May 22 2020 at 10:06):

Mbodin requested coq-makefile-maintainers for a review on PR #12389 Small coq_makefile improvement..

view this post on Zulip Coq Github Bot (May 22 2020 at 10:15):

proux01 updated PR #12076 [coqchk] Fix #5030 (coqchk reports names from opaque modules as axioms) (assigned to ppedrot) from fix-5030 to master:

This is certainly conservative but it is quite simple, fixes the example given in #5030 and is already useful for me (not reporting things like mathcomp.ssreflect.bigop.BigOp.bigopE as axioms).

Fixes #5030

view this post on Zulip Coq Github Bot (May 22 2020 at 10:19):

Mbodin edited PR #12389 Small coq_makefile improvement. from coq_makefile to master:

Kind: feature.

Relates to #7740 and #7722.

The behaviour of coq_makefile regarding DESTDIR is somehow confusing (as seen in the related bug reports above). The “usual” set-up in Linux seems to be:

The COQMF_WINDRIVE parts feels like a hack and is currently undocumented. This PR provides an alternative way (without breaking the previous way):

Being able to set up the installation directory is especially important when using programs like esy, in which different Coq installation can be shared among repositories: esy installs Coq libraries into their own directory, relying on the COQPATH mechanism to link everything back together. By forcing the installation to ${COQLIB}/user-contrib, coq_makefile is installing files in a shared folder, which breaks esy’s invariants required for replication.

view this post on Zulip Coq Github Bot (May 22 2020 at 10:20):

ppedrot submitted PR Review for #12318 Add Ltac2.Constr.Case.{make,nparameters,inductive}

view this post on Zulip Coq Github Bot (May 22 2020 at 10:20):

ppedrot created PR Review Comment on #12318 Add Ltac2.Constr.Case.{make,nparameters,inductive}

I don't think that these primitives should be exposed to the casual user. case is an internal cache, so this should probably go into Unsafe as "an API on which we don't guarantee any stability".

view this post on Zulip Coq Github Bot (May 22 2020 at 11:02):

Zimmi48 submitted PR Review for #11986 [primitive floats] Add low level printing.

view this post on Zulip Coq Github Bot (May 22 2020 at 11:02):

Zimmi48 created PR Review Comment on #11986 [primitive floats] Add low level printing:

Sorry for seeing this too late but you could have linked directly to the doc like this:

  Add flag :flag:`Printing Float` to print primitive floats as hexadecimal

view this post on Zulip Coq Github Bot (May 22 2020 at 11:04):

ppedrot opened Issue #12390 Anomaly with ill-typed arity in inductive types:

In Coq master (ea9463bc10e83759586a41d562e996e1d34e627f):

Inductive T : nat :=.
(* Anomaly "Uncaught exception Reduction.NotArity." *)

This bug was not present in 8.11.

view this post on Zulip Coq Github Bot (May 22 2020 at 11:17):

proux01 submitted PR Review for #11986 [primitive floats] Add low level printing.

view this post on Zulip Coq Github Bot (May 22 2020 at 11:17):

proux01 created PR Review Comment on #11986 [primitive floats] Add low level printing:

Thanks for the information. Maybe not worth a new PR?

view this post on Zulip Coq Github Bot (May 22 2020 at 11:27):

Zimmi48 submitted PR Review for #11986 [primitive floats] Add low level printing.

view this post on Zulip Coq Github Bot (May 22 2020 at 11:27):

Zimmi48 created PR Review Comment on #11986 [primitive floats] Add low level printing:

Yeah, maybe not.

view this post on Zulip Coq Github Bot (May 22 2020 at 15:47):

ppedrot pushed 5 commits to branch master. Commits by proux01 (4) and ppedrot (1).

view this post on Zulip Coq Github Bot (May 22 2020 at 15:47):

ppedrot closed Issue #5030 coqchk reports names from opaque modules as axioms:

Note: the issue was created automatically with bugzilla2github tool

Original bug ID: BZ#5030
From: @RalfJung
Reported version: 8.5

view this post on Zulip Coq Github Bot (May 22 2020 at 15:47):

ppedrot merged PR #12076 [coqchk] Fix #5030 (coqchk reports names from opaque modules as axioms)

view this post on Zulip Coq Github Bot (May 22 2020 at 15:48):

coqbot milestoned Issue #5030 coqchk reports names from opaque modules as axioms:

Note: the issue was created automatically with bugzilla2github tool

Original bug ID: BZ#5030
From: @RalfJung
Reported version: 8.5

view this post on Zulip Coq Github Bot (May 22 2020 at 20:28):

Zimmi48 opened PR #12391 Backport batch of PRs to v8.12. from backport-v8.12 to v8.12:

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: documentation / bug fix / feature / performance / infrastructure.

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #????

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 22 2020 at 20:28):

Zimmi48 edited PR #12391 Backport batch of PRs to v8.12. from backport-v8.12 to v8.12.

view this post on Zulip Coq Github Bot (May 22 2020 at 20:32):

Zimmi48 updated PR #12391 Backport batch of PRs to v8.12. from backport-v8.12 to v8.12.

view this post on Zulip Coq Github Bot (May 22 2020 at 20:43):

Zimmi48 opened PR #12392 [backport-pr] Select correct remote of the master branch. from improve-backport to master:

Kind: infrastructure.

view this post on Zulip Coq Github Bot (May 22 2020 at 20:43):

Zimmi48 milestoned Issue #12392 [backport-pr] Select correct remote of the master branch.

Kind: infrastructure.

view this post on Zulip Coq Github Bot (May 22 2020 at 20:43):

Zimmi48 requested dev-tools-maintainers for a review on PR #12392 [backport-pr] Select correct remote of the master branch..

view this post on Zulip Coq Github Bot (May 22 2020 at 20:52):

JasonGross submitted PR Review for #12392 [backport-pr] Select correct remote of the master branch.

view this post on Zulip Coq Github Bot (May 22 2020 at 20:52):

JasonGross created PR Review Comment on #12392 [backport-pr] Select correct remote of the master branch.

There's the same issue here as I reported in https://github.com/coq/coq/issues/12314. You'll never actually trigger the if branch without making this change

REMOTE=$(git config --get "branch.master.remote" || true)

view this post on Zulip Coq Github Bot (May 22 2020 at 20:52):

JasonGross submitted PR Review for #12392 [backport-pr] Select correct remote of the master branch.

view this post on Zulip Coq Github Bot (May 22 2020 at 21:42):

Zimmi48 submitted PR Review for #12392 [backport-pr] Select correct remote of the master branch.

view this post on Zulip Coq Github Bot (May 22 2020 at 21:42):

Zimmi48 created PR Review Comment on #12392 [backport-pr] Select correct remote of the master branch.

Thanks!

view this post on Zulip Coq Github Bot (May 23 2020 at 11:19):

Zimmi48 updated PR #12392 [backport-pr] Select correct remote of the master branch. from improve-backport to master:

Kind: infrastructure.

view this post on Zulip Coq Github Bot (May 23 2020 at 11:21):

Zimmi48 submitted PR Review for #12392 [backport-pr] Select correct remote of the master branch.

view this post on Zulip Coq Github Bot (May 23 2020 at 11:21):

Zimmi48 created PR Review Comment on #12392 [backport-pr] Select correct remote of the master branch.

@JasonGross Fixed in this tool and all the others.

view this post on Zulip Coq Github Bot (May 23 2020 at 11:25):

Zimmi48 updated PR #12391 Backport batch of PRs to v8.12. from backport-v8.12 to v8.12.

view this post on Zulip Coq Github Bot (May 23 2020 at 12:25):

ejgallego pushed 2 commits to branch v8.12. Commits by ejgallego (1) and ppedrot (1).

view this post on Zulip Coq Github Bot (May 23 2020 at 12:25):

ejgallego merged PR #12363 [8.12] Tweak the OCaml version used to generate the MacOS package.

view this post on Zulip Coq Github Bot (May 23 2020 at 12:37):

Zimmi48 updated PR #12391 Backport batch of PRs to v8.12. from backport-v8.12 to v8.12.

view this post on Zulip Coq Github Bot (May 23 2020 at 12:39):

ejgallego opened PR #12393 [declare] Miscellaneous nits from my main dev tree from declare+misc9 to master:

Some small commits from my dev tree, I think these are for the most part quite trivial, tho we reduce the internal API a bit.

Depends on #12357 [no point in having to do a rebase]

view this post on Zulip Coq Github Bot (May 23 2020 at 12:45):

Zimmi48 edited Issue #11157 Release 8.12 (assigned to Zimmi48):

Release process

As soon as 8.11 has branched off master and 8.12 RM have been nominated do:

About one month before the beta

On the date of the feature freeze

Before the beta release date

These steps are the same for all releases (beta, final, patch-level)

At the final release time

Repeat the generic process documented above for all releases.

At the patch-level release time

We generally do not update the magic numbers at this point (see
2881a18).

Compatibility Infrastructure Update

Additionally, in the same commit, update the compatibility
infrastructure, which consists of invoking
dev/tools/update-compat.py with the
--master flag.

Note that the update-compat.py script must be run twice: once
immediately after branching with the --master flag (which sets
up Coq to support four -compat flag arguments), *in the same
commit* as the one that updates coq_version in
configure.ml, and once again later on before
the next branch point with the --release flag (see next section).

view this post on Zulip Coq Github Bot (May 23 2020 at 12:48):

olaure01 opened Issue #12394 injection does not work with Scheme Equality for type constructors:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Coq 8.5 introduced automatic simplification of sigma-type equalities generated by injection in presence of decidable equality generated by Scheme Equality. It does not work with type constructors such as list:

From Coq Require Import Eqdep_dec.

Inductive Fnat (P : nat -> Type) : nat -> Type :=
| FnatC : forall l, P l -> Fnat P l.

Scheme Equality for nat.

Goal forall P l p p', FnatC P l p = FnatC P l p' -> True.
Proof.
intros P l p p' Heq.
injection Heq as Heqs.
exact I.
Qed.

Inductive Flnat (P : list nat -> Type) : list nat -> Type :=
| FlnatC : forall l, P l -> Flnat P l.

Scheme Equality for list.

Goal forall P l p p', FlnatC P l p = FlnatC P l p' -> True.
Proof.
intros P l p p' Heq.
Fail injection Heq as Heqs.
(* without "Scheme Equality for list."
   it generates
     Heqs : existT (fun l : list nat => P l) l p =
            existT (fun l : list nat => P l) l p'    *)
exact I.
Qed.

Rather than failing, it should at least provide the sigma-type equality (the behavior in Coq 8.4 or without Scheme Equality).

Coq Version

<!-- You can get this information by running coqtop -v. If relevant, please
also include your operating system. -->
from Coq 8.5

view this post on Zulip Coq Github Bot (May 23 2020 at 12:48):

olaure01 labeled Issue #12394 injection does not work with Scheme Equality for type constructors:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Coq 8.5 introduced automatic simplification of sigma-type equalities generated by injection in presence of decidable equality generated by Scheme Equality. It does not work with type constructors such as list:

From Coq Require Import Eqdep_dec.

Inductive Fnat (P : nat -> Type) : nat -> Type :=
| FnatC : forall l, P l -> Fnat P l.

Scheme Equality for nat.

Goal forall P l p p', FnatC P l p = FnatC P l p' -> True.
Proof.
intros P l p p' Heq.
injection Heq as Heqs.
exact I.
Qed.

Inductive Flnat (P : list nat -> Type) : list nat -> Type :=
| FlnatC : forall l, P l -> Flnat P l.

Scheme Equality for list.

Goal forall P l p p', FlnatC P l p = FlnatC P l p' -> True.
Proof.
intros P l p p' Heq.
Fail injection Heq as Heqs.
(* without "Scheme Equality for list."
   it generates
     Heqs : existT (fun l : list nat => P l) l p =
            existT (fun l : list nat => P l) l p'    *)
exact I.
Qed.

Rather than failing, it should at least provide the sigma-type equality (the behavior in Coq 8.4 or without Scheme Equality).

Coq Version

<!-- You can get this information by running coqtop -v. If relevant, please
also include your operating system. -->
from Coq 8.5

view this post on Zulip Coq Github Bot (May 23 2020 at 12:48):

olaure01 labeled Issue #12394 injection does not work with Scheme Equality for type constructors:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Coq 8.5 introduced automatic simplification of sigma-type equalities generated by injection in presence of decidable equality generated by Scheme Equality. It does not work with type constructors such as list:

From Coq Require Import Eqdep_dec.

Inductive Fnat (P : nat -> Type) : nat -> Type :=
| FnatC : forall l, P l -> Fnat P l.

Scheme Equality for nat.

Goal forall P l p p', FnatC P l p = FnatC P l p' -> True.
Proof.
intros P l p p' Heq.
injection Heq as Heqs.
exact I.
Qed.

Inductive Flnat (P : list nat -> Type) : list nat -> Type :=
| FlnatC : forall l, P l -> Flnat P l.

Scheme Equality for list.

Goal forall P l p p', FlnatC P l p = FlnatC P l p' -> True.
Proof.
intros P l p p' Heq.
Fail injection Heq as Heqs.
(* without "Scheme Equality for list."
   it generates
     Heqs : existT (fun l : list nat => P l) l p =
            existT (fun l : list nat => P l) l p'    *)
exact I.
Qed.

Rather than failing, it should at least provide the sigma-type equality (the behavior in Coq 8.4 or without Scheme Equality).

Coq Version

<!-- You can get this information by running coqtop -v. If relevant, please
also include your operating system. -->
from Coq 8.5

view this post on Zulip Coq Github Bot (May 23 2020 at 13:04):

JasonGross submitted PR Review for #12392 [backport-pr] Select correct remote of the master branch.

view this post on Zulip Coq Github Bot (May 23 2020 at 15:08):

ejgallego submitted PR Review for #12393 [declare] Miscellaneous nits from my main dev tree.

view this post on Zulip Coq Github Bot (May 23 2020 at 15:08):

ejgallego created PR Review Comment on #12393 [declare] Miscellaneous nits from my main dev tree:

Next PR will make this unit proof_entry

view this post on Zulip Coq Github Bot (May 23 2020 at 16:05):

Zimmi48 updated PR #12391 Backport batch of PRs to v8.12. from backport-v8.12 to v8.12.

view this post on Zulip Coq Github Bot (May 23 2020 at 16:05):

Zimmi48 pushed 26 commits to branch v8.12. Commits by Zimmi48 (11), proux01 (4), SkySkimmer (3) and others (8).

view this post on Zulip Coq Github Bot (May 23 2020 at 19:49):

MSoegtropIMC updated PR #12186 CReal: changed epsilon for modulus of convergence from 1/n to 1/2^n from creal-new-modulus to master:

This PR changes the epsilon in the definition of the modulus of convergence for CReal from 1/n to 1/2^n. This avoids the issue that in practical high precision computations, even as binary integer n would be quite large (say 2^1000000), although quadratically convergent algorithms might need only a few 10 iterations to reach such a precision.

This is work in progress (right now I just did the main file ConstructiveCauchyReals.v).

@VincentSe : some things I think I should change:

view this post on Zulip Coq Github Bot (May 23 2020 at 23:07):

JasonGross submitted PR Review for #12318 Add Ltac2.Constr.Case.{make,nparameters,inductive}

view this post on Zulip Coq Github Bot (May 23 2020 at 23:07):

JasonGross created PR Review Comment on #12318 Add Ltac2.Constr.Case.{make,nparameters,inductive}

Hm, okay. I think getting the number of parameters from an inductive should be exposed to the user, even without Unsafe. Is there a better way to do this than going through the case info?

view this post on Zulip Coq Github Bot (May 24 2020 at 00:19):

JasonGross edited Issue #11964 native_compute compilation is quadraticish in the number of nested binders in the input:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

Consider:

Require Import Coq.Lists.List.
Inductive type := NAT | LIST (t : type) | ARROW (A B : type).
Fixpoint interpt (t : type) : Set
  := match t with
     | NAT => nat
     | LIST t => list (interpt t)
     | ARROW A B => interpt A -> interpt B
     end.
Inductive expr {var : type -> Type} {ident : type -> Type} : type -> Type :=
| LetIn {A B} : expr A -> (var A -> expr B) -> expr B
| App {A B} : expr (ARROW A B) -> expr A -> expr B
| Ident {A} : ident A -> expr A
| Var {A} : var A -> expr A.
Inductive ident : type -> Type :=
| ident_literal : nat -> ident NAT
| ident_cons : ident (ARROW NAT (ARROW (LIST NAT) (LIST NAT)))
| ident_nil : ident (LIST NAT)
| ident_f : ident (ARROW NAT (ARROW NAT NAT)).
Axiom Let_In : forall {A B : Set}, A -> (A -> B) -> B.
Axiom f : nat -> nat -> nat.
Fixpoint interp (ident_interp : forall t, ident t -> interpt t) {T} (v : expr T) : interpt T
  := match v with
     | LetIn v f => Let_In (interp ident_interp v) (fun v => interp ident_interp (f v))
     | App f x => interp ident_interp f (interp ident_interp x)
     | Var v => v
     | Ident idc => ident_interp _ idc
     end.
Definition ident_interp {t} (idc : ident t) : interpt t
  := match idc with
     | ident_literal x => x
     | ident_cons => fun x xs => cons x xs
     | ident_nil => nil
     | ident_f => fun x y => f x y
     end.

Definition map_double_cps {T} {var} (ls : list (expr (ident:=ident) (var:=var) NAT)) (k : list (expr (ident:=ident) (var:=var) NAT) -> expr (ident:=ident) (var:=var) T) :=
  list_rect
    (fun _ => (list (expr (var:=var) NAT) -> expr T) -> _)
    (fun k => k nil)
    (fun x xs rec k
     => LetIn (App (App (Ident ident_f) x) x)
              (fun y =>
                 rec (fun ys => k (cons (Var y) ys))))
    ls
    k.

Definition make_cps {var} {T} (n : nat) (m : nat) (v : expr (var:=var)(ident:=ident) NAT) (k : list (expr (var:=var) NAT) -> expr T)
  := nat_rect
       _
       (fun k => k (List.repeat v n))
       (fun _ rec k => rec (fun ls => map_double_cps ls k))
       m
       k.
Fixpoint reify_list {var} (ls : list (expr (var:=var) NAT)) : expr (var:=var) (LIST NAT)
  := match ls with
     | nil => Ident ident_nil
     | cons x xs => App (App (Ident ident_cons) x) (reify_list xs)
     end.

Ltac do_up_to tac n :=
  lazymatch n with
  | O => idtac n; tac 0 0
  | S (S (S (S (S ?n')))) => do_up_to tac n'; idtac n; tac n n
  | S ?n' => do_up_to tac n'; idtac n; tac n n
  end.
Ltac mk n m :=
  let preterm := (eval vm_compute in (fun x var => make_cps (T:=LIST NAT) (var:=var) n m (Ident (ident_literal x)) (@reify_list var))) in
  let term := constr:(fun x => interp (@ident_interp) (preterm x _)) in
  term.
Ltac do_time_native_compute n m:=
  let term := mk n m in
  try (once (time "native_compute" (idtac; let res := (eval native_compute in term) in idtac)); fail).
Set NativeCompute Timing.
Goal True.
  (* stack overflows occur starting at 65 *)
  do_up_to do_time_native_compute 60.
Abort.

Processed with

#!/usr/bin/env python
import re
import fileinput
from collections import OrderedDict

REG_N = re.compile(r'^([0-9]*)$')
REG_TAC = re.compile(r'^Tactic call ([^ ]*) ran for ([0-9\.]*) secs .([0-9\.]*)u,([0-9\.]*)s.*$')
REG_NAT = re.compile(r'native_compute: (.*?) done in ([0-9\.]*)\s*$')
def make_table(lines):
    ret = OrderedDict()
    cur_n = None
    for line in lines:
        if line.strip() == '': continue
        mat_n = REG_N.match(line)
        mat_tac = REG_TAC.match(line)
        mat_nat = REG_NAT.match(line)
        if mat_n:
            cur_n = mat_n.groups()[0]
            if cur_n not in ret.keys(): ret[cur_n] = OrderedDict([('n', cur_n), ('binders', str(int(cur_n)**2))])
        elif mat_tac:
            tac, real, user, syst = mat_tac.groups()
            ret[cur_n][tac + ' (real)'] = real
#            ret[cur_n][tac + ' (user)'] = user
#            ret[cur_n][tac + ' (sys)'] = syst
        elif mat_nat:
            kind, t = mat_nat.groups()
            ret[cur_n]['native_compute (%s)' % kind] = t
        else:
            print('None: %s' % line)
    return ret

if __name__ == '__main__':
    tbl = make_table(fileinput.input())
    keys = []
    for row in tbl.values():
        for k in row.keys():
            if k not in keys: keys.append(k)
    print(' | '.join(keys))
    print(' | '.join('--' for i in keys))
    for row in tbl.values():
        print(' | '.join(row.get(k, '') for k in keys))

we get the table

n binders native_compute (Conversion to native code) native_compute (Compilation) native_compute (Evaluation) native_compute (Reification) native_compute (real)
0 0 0.00028 0.10489 0.00051 0.00007 0.106
5 25 0.00101 0.10667 0.00046 0.00046 0.108
10 100 0.00235 0.25455 0.00074 0.00141 0.259
15 225 0.00274 0.67083 0.00097 0.00235 0.677
20 400 0.00448 1.50830 0.00203 0.00540 1.52
25 625 0.00740 3.15089 0.00306 0.00684 3.169
30 900 0.00983 5.87512 0.00371 0.00875 5.898
35 1225 0.01246 10.45606 0.00899 0.00617 10.484
40 1600 0.01415 18.01643 0.00715 0.00864 18.047
45 2025 0.04017 28.58474 0.00746 0.01308 28.647
50 2500 0.02802 51.89912 0.01001 0.01464 51.953
55 3025 0.04674 74.39230 0.00976 0.01674 74.47
60 3600 0.05261 99.43878 0.01100 0.01951 99.528

Here's a plot, showing that it's vaguely quadratic:
![chart (1)](https://user-images.githubusercontent.com/396076/77876108-0c5a8400-7220-11ea-9bb0-41844419e1ac.png)

cc @ppedrot @maximedenes

See also https://github.com/coq/coq/issues/11151

Coq Version

6760a066168a5be0d3b479741fe8ac6c39339610

view this post on Zulip Coq Github Bot (May 24 2020 at 00:40):

JasonGross updated PR #11029 Add a strategy tactic (assigned to ppedrot) from set-strategy to master:

Useful for guarding calls to unfold or cbv to ensure that, e.g.,
Opaque foo doesn't break some automation which tries to unfold foo.

Kind: feature

<strike>I'm confused about gec_gen vs Entry.create vs make_gen_entry, and also I'm getting

File "./theories/Init/Notations.v", line 128, characters 0-32:
Error: Anomaly "grammar function not found: strategy_level."
Please report at http://coq.inria.fr/bugs/.

and don't know how to fix it...</strike>

view this post on Zulip Coq Github Bot (May 24 2020 at 09:50):

ppedrot submitted PR Review for #12318 Add Ltac2.Constr.Case.{make,nparameters,inductive}

view this post on Zulip Coq Github Bot (May 24 2020 at 09:50):

ppedrot created PR Review Comment on #12318 Add Ltac2.Constr.Case.{make,nparameters,inductive}

I'd recommend writing an Inductive module which exposes functions such as nparameters : inductive -> int that fetch that data in the environment.

view this post on Zulip Coq Github Bot (May 24 2020 at 10:17):

Zimmi48 opened Issue #12395 [refman] Version switcher is broken:

The version switcher doesn't appear anymore on https://coq.github.io/doc/master/refman/ and https://coq.github.io/doc/v8.12/refman/. I assume this is a consequence of the update of the version of the theme (part of #12224 that we failed to notice when reviewing the output of this PR).

cc @cpitclaudel (is this something that you think would be easy to fix)

view this post on Zulip Coq Github Bot (May 24 2020 at 10:17):

Zimmi48 labeled Issue #12395 [refman] Version switcher is broken:

The version switcher doesn't appear anymore on https://coq.github.io/doc/master/refman/ and https://coq.github.io/doc/v8.12/refman/. I assume this is a consequence of the update of the version of the theme (part of #12224 that we failed to notice when reviewing the output of this PR).

cc @cpitclaudel (is this something that you think would be easy to fix)

view this post on Zulip Coq Github Bot (May 24 2020 at 10:17):

Zimmi48 labeled Issue #12395 [refman] Version switcher is broken:

The version switcher doesn't appear anymore on https://coq.github.io/doc/master/refman/ and https://coq.github.io/doc/v8.12/refman/. I assume this is a consequence of the update of the version of the theme (part of #12224 that we failed to notice when reviewing the output of this PR).

cc @cpitclaudel (is this something that you think would be easy to fix)

view this post on Zulip Coq Github Bot (May 24 2020 at 10:17):

Zimmi48 milestoned Issue #12395 [refman] Version switcher is broken:

The version switcher doesn't appear anymore on https://coq.github.io/doc/master/refman/ and https://coq.github.io/doc/v8.12/refman/. I assume this is a consequence of the update of the version of the theme (part of #12224 that we failed to notice when reviewing the output of this PR).

cc @cpitclaudel (is this something that you think would be easy to fix)

view this post on Zulip Coq Github Bot (May 24 2020 at 10:34):

Zimmi48 milestoned Issue #12396 Release notes 8.12:

Kind: documentation

This PR consolidates the release notes for 8.12+beta1. It should be a good basis on which @mattam82 can work to prepare a summary of the changes.

The consolidation was initially done thanks to the dev/tools/generate-release-changelog.sh script but I fixed a lot of typos and improved the wording or the links to the doc here and there.

More importantly, I've also reordered the entries by type of change (the order is Changed, Removed, Deprecated, Added, Fixed). I did this because I feel like this makes reading the changelog much easier when there are many entries. The order is chosen so that breaking changes are shown first. If people like this ordering, then we can adapt the changelog infrastructure so that it is automatically sorted like this next time.

I also introduced some new categories: Options, flags and attributes + Commands instead of Commands and options because this category was very long; Reals library (split out of Standard Library because there was much content about this); Reference manual to document all the recent important changes that it received.

The last commit introduces changelog entries about the reference manual (cc @jfehrle).

view this post on Zulip Coq Github Bot (May 24 2020 at 10:34):

Zimmi48 opened PR #12396 Release notes 8.12 from release-notes-8.12 to master:

Kind: documentation

This PR consolidates the release notes for 8.12+beta1. It should be a good basis on which @mattam82 can work to prepare a summary of the changes.

The consolidation was initially done thanks to the dev/tools/generate-release-changelog.sh script but I fixed a lot of typos and improved the wording or the links to the doc here and there.

More importantly, I've also reordered the entries by type of change (the order is Changed, Removed, Deprecated, Added, Fixed). I did this because I feel like this makes reading the changelog much easier when there are many entries. The order is chosen so that breaking changes are shown first. If people like this ordering, then we can adapt the changelog infrastructure so that it is automatically sorted like this next time.

I also introduced some new categories: Options, flags and attributes + Commands instead of Commands and options because this category was very long; Reals library (split out of Standard Library because there was much content about this); Reference manual to document all the recent important changes that it received.

The last commit introduces changelog entries about the reference manual (cc @jfehrle).

view this post on Zulip Coq Github Bot (May 24 2020 at 10:34):

Zimmi48 requested doc-maintainers for a review on PR #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 24 2020 at 12:16):

Zimmi48 submitted PR Review for #12379 Omit voluminous Latex warnings.

view this post on Zulip Coq Github Bot (May 24 2020 at 12:16):

Zimmi48 milestoned Issue #12379 Omit voluminous Latex warnings:

Similar to https://github.com/coq/coq/pull/12195. The -q of that PR didn't make much difference and hid some messages useful for local work.

view this post on Zulip Coq Github Bot (May 24 2020 at 12:16):

Zimmi48 assigned PR #12379 Omit voluminous Latex warnings to Zimmi48.

view this post on Zulip Coq Github Bot (May 24 2020 at 12:18):

Zimmi48 pushed 2 commits to branch master. Commits by Zimmi48 (1) and jfehrle (1).

view this post on Zulip Coq Github Bot (May 24 2020 at 12:18):

Zimmi48 merged PR #12379 Omit voluminous Latex warnings.

view this post on Zulip Coq Github Bot (May 24 2020 at 12:21):

Zimmi48 milestoned Issue #12380 Fix #12361 (indexing issues in the PDF)

Kind: infrastructure.

Follow up to https://github.com/coq/coq/issues/12361.

view this post on Zulip Coq Github Bot (May 24 2020 at 12:22):

Zimmi48 closed without merge PR #12369 Show correct index entries in pdf.

view this post on Zulip Coq Github Bot (May 24 2020 at 12:22):

coqbot demilestoned Issue #12369 Show correct index entries in pdf:

Fixes #12361

view this post on Zulip Coq Github Bot (May 24 2020 at 13:45):

Zimmi48 opened PR #12397 Fix #12280: do not use xindy to avoid build failures on some machines. from do-not-use-xindy to master:

Kind: documentation infrastructure.

Fixes / closes #12280.

The build still goes through and the index still looks fine. Since the manual is entirely written in English, I think there is no issue with using makeindex instead.

view this post on Zulip Coq Github Bot (May 24 2020 at 13:45):

Zimmi48 milestoned Issue #12397 Fix #12280: do not use xindy to avoid build failures on some machines.

Kind: documentation infrastructure.

Fixes / closes #12280.

The build still goes through and the index still looks fine. Since the manual is entirely written in English, I think there is no issue with using makeindex instead.

view this post on Zulip Coq Github Bot (May 24 2020 at 13:45):

Zimmi48 requested ci-maintainers and doc-maintainers for a review on PR #12397 Fix #12280: do not use xindy to avoid build failures on some machines..

view this post on Zulip Coq Github Bot (May 24 2020 at 13:45):

Zimmi48 requested ci-maintainers and doc-maintainers for a review on PR #12397 Fix #12280: do not use xindy to avoid build failures on some machines..

view this post on Zulip Coq Github Bot (May 24 2020 at 13:47):

Zimmi48 updated PR #12397 Fix #12280: do not use xindy to avoid build failures on some machines. from do-not-use-xindy to master:

Kind: documentation infrastructure.

Fixes / closes #12280.

The build still goes through and the index still looks fine. Since the manual is entirely written in English, I think there is no issue with using makeindex instead.

view this post on Zulip Coq Github Bot (May 24 2020 at 14:18):

ejgallego updated PR #12372 [declare] Refactor constant information into a record. from proof+info to master:

This improves the interface, and allows even more sealing of the API.

This is yet work in progress.

view this post on Zulip Coq Github Bot (May 24 2020 at 14:35):

cpitclaudel submitted PR Review for #12397 Fix #12280: do not use xindy to avoid build failures on some machines.

view this post on Zulip Coq Github Bot (May 24 2020 at 15:00):

Zimmi48 milestoned Issue #12398 Allow passing arguments directly to nix-shell.

Kind: infrastructure.

view this post on Zulip Coq Github Bot (May 24 2020 at 15:00):

Zimmi48 opened PR #12398 Allow passing arguments directly to nix-shell. from nix-shell-args to master:

Kind: infrastructure.

view this post on Zulip Coq Github Bot (May 24 2020 at 15:00):

Zimmi48 requested nix-maintainers for a review on PR #12398 Allow passing arguments directly to nix-shell..

view this post on Zulip Coq Github Bot (May 24 2020 at 15:03):

Zimmi48 edited Issue #12332 Reference manual does not build (raises fatal warnings) with Sphinx 3. (assigned to Zimmi48):

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

When building refman-html (via dune or make) the build is stopped by the following fatal warning:

Warning, treated as error:
/home/janno/src/coq/_build/default/doc/sphinx/proof-engine/ltac2.rst:665:duplicate token description of coq:ltac2_term       , other instance in proof-engine/ltac2

<!-- If you can, it's helpful to provide self-contained example of some code
that reproduces the bug. If not, a link to a larger example is also helpful. -->

Coq Version

master+changes from #12329.

Python package versions:

antlr4-python3-runtime==4.8
beautifulsoup4==4.9.0
pexpect==4.8.0
sphinx-rtd-theme==0.4.3
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-bibtex==1.0.0
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==1.0.3
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.4

<!-- You can get this information by running coqtop -v. If relevant, please
also include your operating system. -->

view this post on Zulip Coq Github Bot (May 24 2020 at 15:26):

ppedrot assigned PR #12366 Delay evaluating arguments of the "exists" tactic to ppedrot.

view this post on Zulip Coq Github Bot (May 24 2020 at 15:27):

ppedrot submitted PR Review for #12366 Delay evaluating arguments of the "exists" tactic.

view this post on Zulip Coq Github Bot (May 24 2020 at 15:27):

ppedrot milestoned Issue #12366 Delay evaluating arguments of the "exists" tactic (assigned to ppedrot):

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: bug fix

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #12365

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 24 2020 at 16:15):

ppedrot milestoned Issue #12399 Remove the prolog tactic.

It was deprecated in 8.12 and not used in the wild.

view this post on Zulip Coq Github Bot (May 24 2020 at 16:15):

ppedrot opened PR #12399 Remove the prolog tactic. from rm-prolog to master:

It was deprecated in 8.12 and not used in the wild.

view this post on Zulip Coq Github Bot (May 24 2020 at 16:15):

ppedrot requested tactics-maintainers and ltac-maintainers for a review on PR #12399 Remove the prolog tactic..

view this post on Zulip Coq Github Bot (May 24 2020 at 16:15):

ppedrot requested tactics-maintainers and ltac-maintainers for a review on PR #12399 Remove the prolog tactic..

view this post on Zulip Coq Github Bot (May 24 2020 at 17:02):

JasonGross assigned [PR #12392 [backport-pr] Select correct remote of the master branch.](https://github.com/coq/coq/pull/12392 to JasonGross.

view this post on Zulip Coq Github Bot (May 24 2020 at 17:03):

JasonGross pushed 3 commits to branch master. Commits by Zimmi48 (2) and JasonGross (1).

view this post on Zulip Coq Github Bot (May 24 2020 at 17:03):

JasonGross closed Issue #12314 dev/tools/merge-pr.sh dies silently when the current branch has no remote:

The call
https://github.com/coq/coq/blob/d80458841316ca7edf7317ef412142e27133c931/dev/tools/merge-pr.sh#L84
will cause the script to exit (due to set -e) silently if there is no remote. Perhaps there should be an || true at the end?

view this post on Zulip Coq Github Bot (May 24 2020 at 17:03):

JasonGross merged PR #12392 [backport-pr] Select correct remote of the master branch.

view this post on Zulip Coq Github Bot (May 24 2020 at 17:03):

coqbot milestoned Issue #12314 dev/tools/merge-pr.sh dies silently when the current branch has no remote:

The call
https://github.com/coq/coq/blob/d80458841316ca7edf7317ef412142e27133c931/dev/tools/merge-pr.sh#L84
will cause the script to exit (due to set -e) silently if there is no remote. Perhaps there should be an || true at the end?

view this post on Zulip Coq Github Bot (May 24 2020 at 17:34):

JasonGross updated PR #11029 Add a strategy tactic (assigned to ppedrot) from set-strategy to master:

Useful for guarding calls to unfold or cbv to ensure that, e.g.,
Opaque foo doesn't break some automation which tries to unfold foo.

Kind: feature

<strike>I'm confused about gec_gen vs Entry.create vs make_gen_entry, and also I'm getting

File "./theories/Init/Notations.v", line 128, characters 0-32:
Error: Anomaly "grammar function not found: strategy_level."
Please report at http://coq.inria.fr/bugs/.

and don't know how to fix it...</strike>

view this post on Zulip Coq Github Bot (May 24 2020 at 18:44):

jfehrle submitted PR Review for #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 24 2020 at 18:44):

jfehrle submitted PR Review for #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 24 2020 at 18:44):

jfehrle created PR Review Comment on #12396 Release notes 8.12:

This is idiomatic. Applies in several other places.

  Fehrle, reviewed by Théo Zimmermann).

view this post on Zulip Coq Github Bot (May 24 2020 at 18:44):

jfehrle created PR Review Comment on #12396 Release notes 8.12:

  Most of the grammar is now presented using the notation mechanism that
  has been used to present commands and tactics since Coq 8.8,
  which is documented in :ref:`syntax-conventions`

view this post on Zulip Coq Github Bot (May 24 2020 at 18:44):

jfehrle created PR Review Comment on #12396 Release notes 8.12:

  A selector that allows switching between versions of the reference

view this post on Zulip Coq Github Bot (May 24 2020 at 18:44):

jfehrle created PR Review Comment on #12396 Release notes 8.12:

I'd include a little bit of why as well as what was done.

Mention that sections were reordered to give a more logical organization.

For HTML, split on multiple pages to improve usability. Or say "split into smaller pages".

Wording corrections:

  The reference manual has been restructured.  In the new version,
  there are fewer top-level chapters, and, in the HTML format, chapters
  are split into multiple pages.  This is still a work in progress and
  further restructuring is expected in the next versions of Coq

view this post on Zulip Coq Github Bot (May 24 2020 at 18:44):

jfehrle created PR Review Comment on #12396 Release notes 8.12:

  Most of the documented syntax has been thoroughly updated to make it accurate and
  easily understood.  This was done using a semi-automated `doc_grammar`
  tool introduced for this purpose and through significant revisions to the text.

Still very understated--getting an accurate, readable grammar is a big step forward.
The pre-change grammar was really bad and incomplete.
Still a good bit of syntax that's not explained (e.g. in the terms chapter).

Will we mention the doc improvements (and the plans for subsequent improvements) more prominently, such as in the email announcing the release?

view this post on Zulip Coq Github Bot (May 24 2020 at 18:52):

jfehrle submitted PR Review for #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 24 2020 at 18:52):

jfehrle created PR Review Comment on #12396 Release notes 8.12:

Given that there are 1000 lines describing the changes, how about making them easy to scan/jump to by here adding a list of hyperlinks to the subsections that follow OR making them (sub-)* sections so they appear in the TOC?

view this post on Zulip Coq Github Bot (May 24 2020 at 18:55):

jfehrle submitted PR Review for #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 24 2020 at 18:55):

jfehrle created PR Review Comment on #12396 Release notes 8.12:

Maybe better in the "Tactics" section.

view this post on Zulip Coq Github Bot (May 24 2020 at 20:34):

jfehrle submitted PR Review for #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 24 2020 at 20:57):

JasonGross labeled Issue #12400 Coq's CI fails on at least some developments using native_compute due to incompatible OCaml versions (fiat-crypto)

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

File "/tmp/Coq_native97170a/Coq_native2ba814.native", line 1:
 Error: /builds/coq/coq/_install_ci/lib/coq/kernel/nativevalues.cmi
 is not a compiled interface for this version of OCaml.
 It seems to be for a newer version of OCaml.
 Finished failing transaction in 1.16 secs (0.017u,0.007s) (failure)
 File "./src/UnsaturatedSolinasHeuristics/Tests.v", line 138, characters 0-459:
 Error: Native compiler exited with status 2
 Command exited with non-zero status 1

https://gitlab.com/coq/coq/-/jobs/565436568

cc @coq/ci-maintainers

Coq Version

16e0877c6e3ec6228875e10afb1ec17d640eb1e9

view this post on Zulip Coq Github Bot (May 24 2020 at 20:57):

JasonGross opened Issue #12400 Coq's CI fails on at least some developments using native_compute due to incompatible OCaml versions (fiat-crypto)

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

File "/tmp/Coq_native97170a/Coq_native2ba814.native", line 1:
 Error: /builds/coq/coq/_install_ci/lib/coq/kernel/nativevalues.cmi
 is not a compiled interface for this version of OCaml.
 It seems to be for a newer version of OCaml.
 Finished failing transaction in 1.16 secs (0.017u,0.007s) (failure)
 File "./src/UnsaturatedSolinasHeuristics/Tests.v", line 138, characters 0-459:
 Error: Native compiler exited with status 2
 Command exited with non-zero status 1

https://gitlab.com/coq/coq/-/jobs/565436568

cc @coq/ci-maintainers

Coq Version

16e0877c6e3ec6228875e10afb1ec17d640eb1e9

view this post on Zulip Coq Github Bot (May 24 2020 at 20:57):

JasonGross labeled Issue #12400 Coq's CI fails on at least some developments using native_compute due to incompatible OCaml versions (fiat-crypto)

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

File "/tmp/Coq_native97170a/Coq_native2ba814.native", line 1:
 Error: /builds/coq/coq/_install_ci/lib/coq/kernel/nativevalues.cmi
 is not a compiled interface for this version of OCaml.
 It seems to be for a newer version of OCaml.
 Finished failing transaction in 1.16 secs (0.017u,0.007s) (failure)
 File "./src/UnsaturatedSolinasHeuristics/Tests.v", line 138, characters 0-459:
 Error: Native compiler exited with status 2
 Command exited with non-zero status 1

https://gitlab.com/coq/coq/-/jobs/565436568

cc @coq/ci-maintainers

Coq Version

16e0877c6e3ec6228875e10afb1ec17d640eb1e9

view this post on Zulip Coq Github Bot (May 24 2020 at 21:28):

JasonGross opened Issue #12401 [ci] [engine-bench] "Fatal error: ref_table overflow" is uninformative and missing location info:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

What does this error even mean?
https://gitlab.com/coq/coq/-/jobs/565431385

Coq Version

16e0877c6e3ec6228875e10afb1ec17d640eb1e9

view this post on Zulip Coq Github Bot (May 24 2020 at 21:28):

JasonGross labeled Issue #12401 [ci] [engine-bench] "Fatal error: ref_table overflow" is uninformative and missing location info:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

What does this error even mean?
https://gitlab.com/coq/coq/-/jobs/565431385

Coq Version

16e0877c6e3ec6228875e10afb1ec17d640eb1e9

view this post on Zulip Coq Github Bot (May 24 2020 at 21:40):

JasonGross opened Issue #12402 Docker is sometimes unreliable (ERROR: Preparation failed: Error: No such image registry.gitlab.com/coq/coq:bionic_coq-...)

ERROR: Preparation failed: Error: No such image: registry.gitlab.com/coq/coq:bionic_coq-V2020-05-19-V33 (docker.go:203:0s)

https://gitlab.com/coq/coq/-/jobs/565521645

view this post on Zulip Coq Github Bot (May 24 2020 at 21:40):

JasonGross labeled Issue #12402 Docker is sometimes unreliable (ERROR: Preparation failed: Error: No such image registry.gitlab.com/coq/coq:bionic_coq-...)

ERROR: Preparation failed: Error: No such image: registry.gitlab.com/coq/coq:bionic_coq-V2020-05-19-V33 (docker.go:203:0s)

https://gitlab.com/coq/coq/-/jobs/565521645

view this post on Zulip Coq Github Bot (May 24 2020 at 21:41):

JasonGross labeled Issue #12402 Docker is sometimes unreliable (ERROR: Preparation failed: Error: No such image registry.gitlab.com/coq/coq:bionic_coq-...)

ERROR: Preparation failed: Error: No such image: registry.gitlab.com/coq/coq:bionic_coq-V2020-05-19-V33 (docker.go:203:0s)

https://gitlab.com/coq/coq/-/jobs/565521645

view this post on Zulip Coq Github Bot (May 25 2020 at 02:17):

mdempsky opened PR #12403 Fix hyperlinks in changes.rst from changes-links to master:

Kind: documentation

view this post on Zulip Coq Github Bot (May 25 2020 at 02:17):

mdempsky requested doc-maintainers for a review on PR #12403 Fix hyperlinks in changes.rst.

view this post on Zulip Coq Github Bot (May 25 2020 at 06:07):

ppedrot edited PR #12399 Remove the prolog tactic. from rm-prolog to master:

It was deprecated in 8.12 and not used in the wild.

view this post on Zulip Coq Github Bot (May 25 2020 at 06:07):

ppedrot updated PR #12399 Remove the prolog tactic. from rm-prolog to master:

It was deprecated in 8.12 and not used in the wild.

view this post on Zulip Coq Github Bot (May 25 2020 at 06:07):

ppedrot edited PR #12399 Remove the prolog tactic. from rm-prolog to master:

It was deprecated in 8.12 and not used in the wild.

view this post on Zulip Coq Github Bot (May 25 2020 at 06:46):

Zimmi48 submitted PR Review for #12399 Remove the prolog tactic.

view this post on Zulip Coq Github Bot (May 25 2020 at 08:42):

shiatsumat opened PR #12404 trim new lines in ssreflect-proof-language.rst from patch-1 to master:

Trimmed all redundant new lines after .. coqdoc:: in ssreflect-proof-language.rst.

<!-- Thank you for your contribution.
Make sure you read the contributing guide and fill this template. -->

<!-- Keep what applies -->
Kind: documentation

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->

view this post on Zulip Coq Github Bot (May 25 2020 at 08:42):

shiatsumat requested doc-maintainers for a review on PR #12404 trim new lines in ssreflect-proof-language.rst.

view this post on Zulip Coq Github Bot (May 25 2020 at 09:07):

SkySkimmer unlabeled Issue #12401 [ci] [engine-bench] "Fatal error: ref_table overflow" is uninformative and missing location info:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

What does this error even mean?
https://gitlab.com/coq/coq/-/jobs/565431385

Coq Version

16e0877c6e3ec6228875e10afb1ec17d640eb1e9

view this post on Zulip Coq Github Bot (May 25 2020 at 09:07):

SkySkimmer edited Issue #12401 [engine-bench] "Fatal error: ref_table overflow" is uninformative and missing location info:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

What does this error even mean?
https://gitlab.com/coq/coq/-/jobs/565431385

Coq Version

16e0877c6e3ec6228875e10afb1ec17d640eb1e9

view this post on Zulip Coq Github Bot (May 25 2020 at 09:12):

gares submitted PR Review for #12389 Small coq_makefile improvement.

view this post on Zulip Coq Github Bot (May 25 2020 at 09:14):

gares assigned [PR #12389 Small coq_makefile improvement.](https://github.com/coq/coq/pull/12389 to gares.

view this post on Zulip Coq Github Bot (May 25 2020 at 09:14):

gares milestoned Issue #12389 Small coq_makefile improvement. (assigned to gares):

Kind: feature.

Relates to #7740 and #7722.

The behaviour of coq_makefile regarding DESTDIR is somehow confusing (as seen in the related bug reports above). The “usual” set-up in Linux seems to be:

The COQMF_WINDRIVE parts feels like a hack and is currently undocumented. This PR provides an alternative way (without breaking the previous way):

Being able to set up the installation directory is especially important when using programs like esy, in which different Coq installation can be shared among repositories: esy installs Coq libraries into their own directory, relying on the COQPATH mechanism to link everything back together. By forcing the installation to ${COQLIB}/user-contrib, coq_makefile is installing files in a shared folder, which breaks esy’s invariants required for replication.

view this post on Zulip Coq Github Bot (May 25 2020 at 09:42):

SkySkimmer opened PR #12405 Stop using flambda for fiat-crypto connected jobs from stop-flambda-bignums to master:

Fix #12400

view this post on Zulip Coq Github Bot (May 25 2020 at 09:42):

SkySkimmer requested ci-maintainers for a review on PR #12405 Stop using flambda for fiat-crypto connected jobs.

view this post on Zulip Coq Github Bot (May 25 2020 at 09:42):

Blaisorblade opened Issue #12406 Type error in dependent induction

Description of the problem

The definition of elim_tac in theories/Program/Equality.v is ill-typed (as noticed by @mattam82), causing dependent induction to sometimes produce ill-typed terms — here's the needed fix:

Ltac elim_tac tac p ::=
  let ty := type of p in

-  let eliminator := eval simpl in (@elim (_ : DependentEliminationPackage ty)) in
+  let eliminator := eval simpl in (@elim _ (_ : DependentEliminationPackage ty)) in
    tac p eliminator.

elim comes from

Class DependentEliminationPackage (A : Type) :=
  { elim_type : Type ; elim : elim_type }.

My attempt using that run into further problems (maybe #8275), but I guess this should still be fixed. I'll try to send a PR, even tho I don't have a testcase.

(Sorry for the incomplete issue, not sure I'll get to file a better one).

Coq Version

8.11.1

view this post on Zulip Coq Github Bot (May 25 2020 at 09:42):

SkySkimmer milestoned Issue #12405 Stop using flambda for fiat-crypto connected jobs:

Fix #12400

view this post on Zulip Coq Github Bot (May 25 2020 at 09:45):

Blaisorblade opened PR #12407 Fix #12406: fix Coq type error in dependent induction's Ltac from dep-ind-fix-ltac-type-error to master:

<!-- Keep what applies -->
Kind: bug fix.

<!-- If this is a bug fix, make sure the bug was reported beforehand. -->
Fixes / closes #12406

<!-- If there is a user-visible change in coqc/coqtop/coqchk/coq_makefile behavior and testing is not prohibitively expensive: -->
<!-- (Otherwise, remove this line.) -->

view this post on Zulip Coq Github Bot (May 25 2020 at 09:46):

proux01 updated PR #12218 Numeral notations for non inductive types from numeral-notations-non-inductive to master:

This is a tentative implementation of the idea discussed in #12035

This is a draft PR due to the fact that it is still lacking some proofs and proper documentation.

Numeral Notation non_inductive via inductive using ...

The main idea is to use actual inductive types that map what you want to parse/print and just translate to (resp. from) the actual type from (resp. to) this inductive type after calling the parser (resp before the printer). One then just has to provide a mapping from globrefs of the actual type to constructors of the inductive type.

For instance, for reals, that looks something like

Inductive IZ :=
| IZpow_pos : Z -> positive -> IZ
| IZ0 : IZ
| IZpos : positive -> IZ
| IZneg : positive -> IZ.

Inductive IR :=
| IRZ : IZ -> IR
| IRQ : Q -> IR
| IRmult : IR -> IR -> IR
| IRdiv : IR -> IR -> IR.

[..]  (* define parser numeral_to_IR and printer IR_to_numeral *)

Numeral Notation R via IR
  using (IZR IRZ, Q2R IRQ, Rmult IRmult, Rdiv IRdiv,
         Z.pow_pos IZpow_pos, Z0 IZ0, Zpos IZpos, Zneg IZneg)
  numeral_to_IR IR_to_numeral : R_scope.

Two notations are provided as examples for Q and R.

Q

Previously rationals were all parsed as a pair numerator, denominator. This means 1.02 and 102e-2 were both parsed as 102 # 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is still parsed as a power of ten denominator but exponents are parsed as a product or division by Z.pow_pos. For instance, 1.02 is parsed as 102 # 100 whereas 102e-2 is parsed as (102 # 1) / (Z.pow_pos 10 2 # 1).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = (102 # 100) * (10 # 1) = 1020 # 100 and 10.2 = 102 # 10 no longer are.

A nice side effect is that exponents can no longer blow up during parsing. Previously 1e1_000_000 literally produced a numerator with a million digits, now it just yields (1 # 1) * (Z.pow_pos 10 1_000_000 # 1).

R

Previously real constants were parsed by an unproved OCaml code. The parser and printer are now implemented in Coq, which will enable a proof and hopefully make it easier to maintain / make evolve.

Previously reals were all parsed as an integer, an integer multiplied by a power of ten or an integer divided by a power of ten. This means 1.02 and 102e-2 were both parsed as 102 / 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is parsed as a rational and exponents are parsed as a product or division by a power of ten. For instance, 1.02 is parsed as Q2R (102 # 100) whereas 102e-2 is parsed as IZR 102 / IZR (Z.pow_pos 10 2).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = Q2R (102 # 100) * 10 and 10.2 = Q2R (102 # 10) no longer are.

TODO

~Depends from: #11948~

view this post on Zulip Coq Github Bot (May 25 2020 at 10:27):

proux01 edited PR #12218 Numeral notations for non inductive types from numeral-notations-non-inductive to master:

This is a tentative implementation of the idea discussed in #12035

This is still lacking some proofs and proper documentation.

Numeral Notation non_inductive via inductive using ...

The main idea is to use actual inductive types that map what you want to parse/print and just translate to (resp. from) the actual type from (resp. to) this inductive type after calling the parser (resp before the printer). One then just has to provide a mapping from globrefs of the actual type to constructors of the inductive type.

For instance, for reals, that looks something like

Inductive IZ :=
| IZpow_pos : Z -> positive -> IZ
| IZ0 : IZ
| IZpos : positive -> IZ
| IZneg : positive -> IZ.

Inductive IR :=
| IRZ : IZ -> IR
| IRQ : Q -> IR
| IRmult : IR -> IR -> IR
| IRdiv : IR -> IR -> IR.

[..]  (* define parser numeral_to_IR and printer IR_to_numeral *)

Numeral Notation R via IR
  using (IZR IRZ, Q2R IRQ, Rmult IRmult, Rdiv IRdiv,
         Z.pow_pos IZpow_pos, Z0 IZ0, Zpos IZpos, Zneg IZneg)
  numeral_to_IR IR_to_numeral : R_scope.

Two notations are provided as examples for Q and R.

Q

Previously rationals were all parsed as a pair numerator, denominator. This means 1.02 and 102e-2 were both parsed as 102 # 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is still parsed as a power of ten denominator but exponents are parsed as a product or division by Z.pow_pos. For instance, 1.02 is parsed as 102 # 100 whereas 102e-2 is parsed as (102 # 1) / (Z.pow_pos 10 2 # 1).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = (102 # 100) * (10 # 1) = 1020 # 100 and 10.2 = 102 # 10 no longer are.

A nice side effect is that exponents can no longer blow up during parsing. Previously 1e1_000_000 literally produced a numerator with a million digits, now it just yields (1 # 1) * (Z.pow_pos 10 1_000_000 # 1).

R

Previously real constants were parsed by an unproved OCaml code. The parser and printer are now implemented in Coq, which will enable a proof and hopefully make it easier to maintain / make evolve.

Previously reals were all parsed as an integer, an integer multiplied by a power of ten or an integer divided by a power of ten. This means 1.02 and 102e-2 were both parsed as 102 / 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is parsed as a rational and exponents are parsed as a product or division by a power of ten. For instance, 1.02 is parsed as Q2R (102 # 100) whereas 102e-2 is parsed as IZR 102 / IZR (Z.pow_pos 10 2).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = Q2R (102 # 100) * 10 and 10.2 = Q2R (102 # 10) no longer are.

TODO

~Depends from: #11948~

view this post on Zulip Coq Github Bot (May 25 2020 at 11:14):

ejgallego updated PR #12393 [declare] Miscellaneous nits from my main dev tree from declare+misc9 to master:

Some small commits from my dev tree, I think these are for the most part quite trivial, tho we reduce the internal API a bit.

Depends on #12357 [no point in having to do a rebase]

view this post on Zulip Coq Github Bot (May 25 2020 at 11:39):

ejgallego closed without merge PR #12142 [proof] Split vio and regular proof close paths.

view this post on Zulip Coq Github Bot (May 25 2020 at 12:12):

proux01 updated PR #12218 Numeral notations for non inductive types from numeral-notations-non-inductive to master:

This is a tentative implementation of the idea discussed in #12035

This is still lacking some proofs and proper documentation.

Numeral Notation non_inductive via inductive using ...

The main idea is to use actual inductive types that map what you want to parse/print and just translate to (resp. from) the actual type from (resp. to) this inductive type after calling the parser (resp before the printer). One then just has to provide a mapping from globrefs of the actual type to constructors of the inductive type.

For instance, for reals, that looks something like

Inductive IZ :=
| IZpow_pos : Z -> positive -> IZ
| IZ0 : IZ
| IZpos : positive -> IZ
| IZneg : positive -> IZ.

Inductive IR :=
| IRZ : IZ -> IR
| IRQ : Q -> IR
| IRmult : IR -> IR -> IR
| IRdiv : IR -> IR -> IR.

[..]  (* define parser numeral_to_IR and printer IR_to_numeral *)

Numeral Notation R via IR
  using (IZR IRZ, Q2R IRQ, Rmult IRmult, Rdiv IRdiv,
         Z.pow_pos IZpow_pos, Z0 IZ0, Zpos IZpos, Zneg IZneg)
  numeral_to_IR IR_to_numeral : R_scope.

Two notations are provided as examples for Q and R.

Q

Previously rationals were all parsed as a pair numerator, denominator. This means 1.02 and 102e-2 were both parsed as 102 # 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is still parsed as a power of ten denominator but exponents are parsed as a product or division by Z.pow_pos. For instance, 1.02 is parsed as 102 # 100 whereas 102e-2 is parsed as (102 # 1) / (Z.pow_pos 10 2 # 1).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = (102 # 100) * (10 # 1) = 1020 # 100 and 10.2 = 102 # 10 no longer are.

A nice side effect is that exponents can no longer blow up during parsing. Previously 1e1_000_000 literally produced a numerator with a million digits, now it just yields (1 # 1) * (Z.pow_pos 10 1_000_000 # 1).

R

Previously real constants were parsed by an unproved OCaml code. The parser and printer are now implemented in Coq, which will enable a proof and hopefully make it easier to maintain / make evolve.

Previously reals were all parsed as an integer, an integer multiplied by a power of ten or an integer divided by a power of ten. This means 1.02 and 102e-2 were both parsed as 102 / 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is parsed as a rational and exponents are parsed as a product or division by a power of ten. For instance, 1.02 is parsed as Q2R (102 # 100) whereas 102e-2 is parsed as IZR 102 / IZR (Z.pow_pos 10 2).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = Q2R (102 # 100) * 10 and 10.2 = Q2R (102 # 10) no longer are.

TODO

~Depends from: #11948~

view this post on Zulip Coq Github Bot (May 25 2020 at 13:06):

Zimmi48 milestoned Issue #12408 Fix output tests for location errors when running in async mode.

In this mode, an additional error was emitted, which made the test fail:
Error: There are pending proofs: Unnamed_thm.

Kind: fix

view this post on Zulip Coq Github Bot (May 25 2020 at 13:06):

Zimmi48 opened PR #12408 Fix output tests for location errors when running in async mode. from fix-error-location-tests-async to master:

In this mode, an additional error was emitted, which made the test fail:
Error: There are pending proofs: Unnamed_thm.

Kind: fix

view this post on Zulip Coq Github Bot (May 25 2020 at 13:12):

ejgallego updated PR #12372 [declare] Refactor constant information into a record. from proof+info to master:

This improves the interface, and allows even more sealing of the API.

This is yet work in progress.

view this post on Zulip Coq Github Bot (May 25 2020 at 13:22):

Zimmi48 submitted PR Review for #12405 Stop using flambda for fiat-crypto connected jobs.

view this post on Zulip Coq Github Bot (May 25 2020 at 13:22):

Zimmi48 assigned PR #12405 Stop using flambda for fiat-crypto connected jobs to Zimmi48.

view this post on Zulip Coq Github Bot (May 25 2020 at 14:26):

Zimmi48 submitted PR Review for #12403 Fix hyperlinks in changes.rst.

view this post on Zulip Coq Github Bot (May 25 2020 at 14:26):

Zimmi48 assigned PR #12403 Fix hyperlinks in changes.rst to Zimmi48.

view this post on Zulip Coq Github Bot (May 25 2020 at 14:26):

Zimmi48 milestoned Issue #12403 Fix hyperlinks in changes.rst (assigned to Zimmi48):

Kind: documentation

view this post on Zulip Coq Github Bot (May 25 2020 at 14:27):

Zimmi48 pushed 2 commits to branch master. Commits by Zimmi48 (1) and mdempsky (1).

view this post on Zulip Coq Github Bot (May 25 2020 at 14:27):

Zimmi48 merged PR #12403 Fix hyperlinks in changes.rst.

view this post on Zulip Coq Github Bot (May 25 2020 at 14:56):

ejgallego updated PR #12372 [declare] Refactor constant information into a record. from proof+info to master:

This improves the interface, and allows even more sealing of the API.

This is yet work in progress.

view this post on Zulip Coq Github Bot (May 25 2020 at 16:05):

JasonGross submitted PR Review for #12408 Fix output tests for location errors when running in async mode.

view this post on Zulip Coq Github Bot (May 25 2020 at 16:25):

VincentSe opened PR #12409 Parametric rings from ParametricRings to master:

Kind: feature

Make Add Ring parametric, so that we can register families of rings like
Add Parametric Ring CRRing (R : ConstructiveReals) : (CRisRing R).

view this post on Zulip Coq Github Bot (May 25 2020 at 16:25):

VincentSe requested reals-library-maintainers, ring-maintainers, kernel-maintainers and ltac-maintainers for a review on PR #12409 Parametric rings.

view this post on Zulip Coq Github Bot (May 25 2020 at 16:25):

VincentSe requested reals-library-maintainers, ring-maintainers, kernel-maintainers and ltac-maintainers for a review on PR #12409 Parametric rings.

view this post on Zulip Coq Github Bot (May 25 2020 at 16:25):

VincentSe requested reals-library-maintainers, ring-maintainers, kernel-maintainers and ltac-maintainers for a review on PR #12409 Parametric rings.

view this post on Zulip Coq Github Bot (May 25 2020 at 16:25):

VincentSe requested reals-library-maintainers, ring-maintainers, kernel-maintainers and ltac-maintainers for a review on PR #12409 Parametric rings.

view this post on Zulip Coq Github Bot (May 25 2020 at 16:51):

Zimmi48 updated PR #12408 Fix output tests for location errors when running in async mode. from fix-error-location-tests-async to master:

In this mode, an additional error was emitted, which made the test fail:
Error: There are pending proofs: Unnamed_thm.

Kind: fix

view this post on Zulip Coq Github Bot (May 25 2020 at 17:19):

fajb updated PR #11906 [micromega] native support for boolean operators from bmicromega to master:

Kind: feature
(this is a clean revival of #11047 )

view this post on Zulip Coq Github Bot (May 25 2020 at 17:25):

ppedrot pushed 3 commits to branch master. Commits by SkySkimmer (2) and ppedrot (1).

view this post on Zulip Coq Github Bot (May 25 2020 at 17:25):

ppedrot merged PR #12344 Cleanup noisy prefixes.

view this post on Zulip Coq Github Bot (May 25 2020 at 17:26):

ppedrot pushed 2 commits to branch master. Commits by gasparattila (1) and ppedrot (1).

view this post on Zulip Coq Github Bot (May 25 2020 at 17:26):

ppedrot closed Issue #12365 "exists a, b" can fail even if "exists a; exists b" succeeds:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

<!-- If you can, it's helpful to provide self-contained example of some code
that reproduces the bug. If not, a link to a larger example is also helpful. -->

Parameter a b : nat.
Parameter p : a = b.

Goal exists (_ : True) (_ : exists x, x = b), True.
Proof.
  Fail exists I, (ex_intro _ a p).
  exists I; exists (ex_intro _ a p).

The failure is caused by the evar constraints from ex_intro _ a p being present when I is used. These constraints cannot be solved by unification without additional information from the goal.

Coq Version

8.11.0
<!-- You can get this information by running coqtop -v. If relevant, please
also include your operating system. -->

view this post on Zulip Coq Github Bot (May 25 2020 at 17:26):

ppedrot merged PR #12366 Delay evaluating arguments of the "exists" tactic.

view this post on Zulip Coq Github Bot (May 25 2020 at 17:26):

coqbot milestoned Issue #12365 "exists a, b" can fail even if "exists a; exists b" succeeds:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

<!-- If you can, it's helpful to provide self-contained example of some code
that reproduces the bug. If not, a link to a larger example is also helpful. -->

Parameter a b : nat.
Parameter p : a = b.

Goal exists (_ : True) (_ : exists x, x = b), True.
Proof.
  Fail exists I, (ex_intro _ a p).
  exists I; exists (ex_intro _ a p).

The failure is caused by the evar constraints from ex_intro _ a p being present when I is used. These constraints cannot be solved by unification without additional information from the goal.

Coq Version

8.11.0
<!-- You can get this information by running coqtop -v. If relevant, please
also include your operating system. -->

view this post on Zulip Coq Github Bot (May 25 2020 at 17:28):

ppedrot submitted PR Review for #12409 Parametric rings.

view this post on Zulip Coq Github Bot (May 25 2020 at 17:28):

ppedrot created PR Review Comment on #12409 Parametric rings:

Why the renaming? I was under the impression that the current preferred naming scheme was sigma rather than evd.

view this post on Zulip Coq Github Bot (May 25 2020 at 17:34):

VincentSe submitted PR Review for #12409 Parametric rings.

view this post on Zulip Coq Github Bot (May 25 2020 at 17:34):

VincentSe created PR Review Comment on #12409 Parametric rings:

This one slipped after the squash, I'll roll it back.

view this post on Zulip Coq Github Bot (May 25 2020 at 17:34):

ppedrot submitted PR Review for #12409 Parametric rings.

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

You probably meant in ltac_expr0.

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

The syntax only exists with the leading ltac_expr:

.. tacn:: ltac_expr__seq ; [ {? @for_each_goal } ]

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

Let's be clearer:

   :n:`[> @tactic_list | .. | @tactic_list ]`

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

.. tacn:: [> @for_each_goal ]

This can already be empty given the definition of a tactic_list.

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

   must be lower than or equal to the number of focused goals.

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

You could even say:

   :tacn:`only` is one of the :token:`l3_tactics`.

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

If you do decide to apply the previous suggestion of referring to l3_tactics, then this and the rest of such sentences should be modified as well.

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

   :n:`@ltac_expr` is evaluated to ``v`` which must be a tactic value. The tactic value ``v``

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

   The do loop repeats a tactic :token:`int_or_var` times:

Same change necessary in the paragraph below.

view this post on Zulip Coq Github Bot (May 25 2020 at 18:09):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

This example makes me realize that we should really find a better name for the tactic_list we introduced. The best alternative name I could find is: goal_tactics.

view this post on Zulip Coq Github Bot (May 25 2020 at 20:30):

VincentSe updated PR #12409 Parametric rings from ParametricRings to master:

Kind: feature

Make Add Ring parametric, so that we can register families of rings like
Add Parametric Ring CRRing (R : ConstructiveReals) : (CRisRing R).

view this post on Zulip Coq Github Bot (May 25 2020 at 21:03):

MSoegtropIMC updated PR #12186 CReal: changed epsilon for modulus of convergence from 1/n to 1/2^n from creal-new-modulus to master:

This PR changes the epsilon in the definition of the modulus of convergence for CReal from 1/n to 1/2^n. This avoids the issue that in practical high precision computations, even as binary integer n would be quite large (say 2^1000000), although quadratically convergent algorithms might need only a few 10 iterations to reach such a precision.

This is work in progress (right now I just did the main file ConstructiveCauchyReals.v).

@VincentSe : some things I think I should change:

view this post on Zulip Coq Github Bot (May 25 2020 at 23:14):

JasonGross milestoned Issue #12410 dev/tools/make-changelog.sh now asks about fixed bugs:

Fixes #12386

Kind: infrastructure.

view this post on Zulip Coq Github Bot (May 25 2020 at 23:14):

JasonGross opened PR #12410 dev/tools/make-changelog.sh now asks about fixed bugs from add-fixes to master:

Fixes #12386

Kind: infrastructure.

view this post on Zulip Coq Github Bot (May 25 2020 at 23:14):

JasonGross requested dev-tools-maintainers for a review on PR #12410 dev/tools/make-changelog.sh now asks about fixed bugs.

view this post on Zulip Coq Github Bot (May 25 2020 at 23:18):

JasonGross opened PR #12411 Add support for CoqMakefile.local-late from makefile-local-late to master:

This allows users to write rules that depend on variables such as
VOFILES and VDFILE, which is essential in some of my use-cases (for
example, to properly handle seamless version switching, I need to make
all of the .vo files depend on a file where I record the version of Coq
being used).

Fixes #10912

Kind: feature / infrastructure.

Does this qualify for 8.12 / 8.12+beta1?

view this post on Zulip Coq Github Bot (May 25 2020 at 23:18):

JasonGross requested doc-maintainers and coq-makefile-maintainers for a review on PR #12411 Add support for CoqMakefile.local-late.

view this post on Zulip Coq Github Bot (May 25 2020 at 23:18):

JasonGross requested doc-maintainers and coq-makefile-maintainers for a review on PR #12411 Add support for CoqMakefile.local-late.

view this post on Zulip Coq Github Bot (May 26 2020 at 05:03):

jfehrle submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 05:03):

jfehrle created PR Review Comment on #12103 Convert Ltac chapter to prodn:

simple_tactic is in l1_tactics.

view this post on Zulip Coq Github Bot (May 26 2020 at 05:32):

jfehrle submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 05:32):

jfehrle created PR Review Comment on #12103 Convert Ltac chapter to prodn:

Sometimes such redundancy is helpful to the user. In this case, [> ] is a no-op, it's not really useful. I will change.

view this post on Zulip Coq Github Bot (May 26 2020 at 05:36):

JasonGross submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 05:36):

JasonGross created PR Review Comment on #12103 Convert Ltac chapter to prodn:

Huh? [ > ] is not a no-op, it fails if the number of goals is not equal to 1. It's [ > .. ] that's a no-op.

view this post on Zulip Coq Github Bot (May 26 2020 at 05:40):

jfehrle submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 05:40):

jfehrle created PR Review Comment on #12103 Convert Ltac chapter to prodn:

It's fine. I use the same phrasing elsewhere.

view this post on Zulip Coq Github Bot (May 26 2020 at 07:44):

jfehrle updated PR #12103 Convert Ltac chapter to prodn (assigned to Zimmi48) from prodn_ltac to master:

A strategy question for now, don't read more than you have to.

I think the two-page long grammar in the Syntax section doesn't work.

I think I can live with making all the tacticals as tacn::, but we may need to add comments on them saying which ltac_expr* they're associated with this since that has some effect on how the expression is interpreted (precedence).

Then there would be 2 possibilities for that syntax block:

I'd go for the first option. Also, I need to make sure I understand how the precedence works.

Your thoughts?

Fix #11932

view this post on Zulip Coq Github Bot (May 26 2020 at 08:05):

jfehrle updated PR #12103 Convert Ltac chapter to prodn (assigned to Zimmi48) from prodn_ltac to master:

A strategy question for now, don't read more than you have to.

I think the two-page long grammar in the Syntax section doesn't work.

I think I can live with making all the tacticals as tacn::, but we may need to add comments on them saying which ltac_expr* they're associated with this since that has some effect on how the expression is interpreted (precedence).

Then there would be 2 possibilities for that syntax block:

I'd go for the first option. Also, I need to make sure I understand how the precedence works.

Your thoughts?

Fix #11932

view this post on Zulip Coq Github Bot (May 26 2020 at 08:09):

jfehrle updated PR #12103 Convert Ltac chapter to prodn (assigned to Zimmi48) from prodn_ltac to master:

A strategy question for now, don't read more than you have to.

I think the two-page long grammar in the Syntax section doesn't work.

I think I can live with making all the tacticals as tacn::, but we may need to add comments on them saying which ltac_expr* they're associated with this since that has some effect on how the expression is interpreted (precedence).

Then there would be 2 possibilities for that syntax block:

I'd go for the first option. Also, I need to make sure I understand how the precedence works.

Your thoughts?

Fix #11932

view this post on Zulip Coq Github Bot (May 26 2020 at 08:48):

Zimmi48 opened PR #12412 Reduce options passed to workers from reduce-options-passed-to-workers to master:

Kind: fix.

If I understood @gares correctly on Zulip, the -ri and variants and the -set and variants do not need to be passed to the workers because they have been applied in the initial state that is passed to the workers. If this is correct, this should fix the failing interleave_options_bad_order test with async.

view this post on Zulip Coq Github Bot (May 26 2020 at 08:48):

Zimmi48 milestoned Issue #12412 Reduce options passed to workers:

Kind: fix.

If I understood @gares correctly on Zulip, the -ri and variants and the -set and variants do not need to be passed to the workers because they have been applied in the initial state that is passed to the workers. If this is correct, this should fix the failing interleave_options_bad_order test with async.

view this post on Zulip Coq Github Bot (May 26 2020 at 08:48):

Zimmi48 requested stm-maintainers for a review on PR #12412 Reduce options passed to workers.

view this post on Zulip Coq Github Bot (May 26 2020 at 09:43):

SkySkimmer submitted PR Review for #12388 Fix an uncaught python exception in timing.

view this post on Zulip Coq Github Bot (May 26 2020 at 09:43):

SkySkimmer assigned PR #12388 Fix an uncaught python exception in timing to SkySkimmer.

view this post on Zulip Coq Github Bot (May 26 2020 at 09:47):

Mbodin requested doc-maintainers for a review on PR #12389 Small coq_makefile improvement..

view this post on Zulip Coq Github Bot (May 26 2020 at 09:47):

Mbodin updated PR #12389 Small coq_makefile improvement. (assigned to gares) from coq_makefile to master:

Kind: feature.

Relates to #7740 and #7722.

The behaviour of coq_makefile regarding DESTDIR is somehow confusing (as seen in the related bug reports above). The “usual” set-up in Linux seems to be:

The COQMF_WINDRIVE parts feels like a hack and is currently undocumented. This PR provides an alternative way (without breaking the previous way):

Being able to set up the installation directory is especially important when using programs like esy, in which different Coq installation can be shared among repositories: esy installs Coq libraries into their own directory, relying on the COQPATH mechanism to link everything back together. By forcing the installation to ${COQLIB}/user-contrib, coq_makefile is installing files in a shared folder, which breaks esy’s invariants required for replication.

view this post on Zulip Coq Github Bot (May 26 2020 at 09:50):

SkySkimmer submitted PR Review for #12412 Reduce options passed to workers.

view this post on Zulip Coq Github Bot (May 26 2020 at 09:50):

SkySkimmer created PR Review Comment on #12412 Reduce options passed to workers:

You need to add them to "options to discard" not just delete them.

view this post on Zulip Coq Github Bot (May 26 2020 at 09:53):

Zimmi48 submitted PR Review for #12412 Reduce options passed to workers.

view this post on Zulip Coq Github Bot (May 26 2020 at 09:53):

Zimmi48 created PR Review Comment on #12412 Reduce options passed to workers:

OK thanks!

view this post on Zulip Coq Github Bot (May 26 2020 at 09:54):

Zimmi48 edited PR Review Comment on #12412 Reduce options passed to workers.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:08):

Zimmi48 updated PR #12412 Reduce options passed to workers from reduce-options-passed-to-workers to master:

Kind: fix.

If I understood @gares correctly on Zulip, the -ri and variants and the -set and variants do not need to be passed to the workers because they have been applied in the initial state that is passed to the workers. If this is correct, this should fix the failing interleave_options_bad_order test with async.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:08):

Zimmi48 requested stm-maintainers and toplevel-maintainers for a review on PR #12412 Reduce options passed to workers.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:09):

Zimmi48 submitted PR Review for #12412 Reduce options passed to workers.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:09):

Zimmi48 created PR Review Comment on #12412 Reduce options passed to workers:

Should be better now.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:17):

SkySkimmer pushed 2 commits to branch master. Commits by JasonGross (1) and SkySkimmer (1).

view this post on Zulip Coq Github Bot (May 26 2020 at 10:17):

SkySkimmer closed Issue #12387 make print-pretty-timed-diff will raise a python exception if either "before" or "after" has no files (assigned to JasonGross):

Traceback (most recent call last):
  File "/home/jgross/Documents/repos/coq/tools/make-both-time-files.py", line 16, in <module>
    table = make_diff_table_string(left_dict, right_dict, sort_by=args.sort_by, include_mem=args.include_mem, sort_by_mem=args.sort_by_mem)
  File "/home/jgross/Documents/repos/coq/tools/TimeFileMaker.py", line 391, in make_diff_table_string
    right_peak = max(v.get(MEM_KEY, 0) for v in right_dict.values())
ValueError: max() arg is an empty sequence

view this post on Zulip Coq Github Bot (May 26 2020 at 10:17):

SkySkimmer merged PR #12388 Fix an uncaught python exception in timing.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:17):

coqbot milestoned Issue #12387 make print-pretty-timed-diff will raise a python exception if either "before" or "after" has no files (assigned to JasonGross):

Traceback (most recent call last):
  File "/home/jgross/Documents/repos/coq/tools/make-both-time-files.py", line 16, in <module>
    table = make_diff_table_string(left_dict, right_dict, sort_by=args.sort_by, include_mem=args.include_mem, sort_by_mem=args.sort_by_mem)
  File "/home/jgross/Documents/repos/coq/tools/TimeFileMaker.py", line 391, in make_diff_table_string
    right_peak = max(v.get(MEM_KEY, 0) for v in right_dict.values())
ValueError: max() arg is an empty sequence

view this post on Zulip Coq Github Bot (May 26 2020 at 10:18):

SkySkimmer submitted PR Review for #12397 Fix #12280: do not use xindy to avoid build failures on some machines.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:18):

SkySkimmer submitted PR Review for #12397 Fix #12280: do not use xindy to avoid build failures on some machines.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:18):

SkySkimmer created PR Review Comment on #12397 Fix #12280: do not use xindy to avoid build failures on some machines.

Maybe add a comment about why we do this

view this post on Zulip Coq Github Bot (May 26 2020 at 10:20):

Zimmi48 edited PR #12389 Small coq_makefile improvement. (assigned to gares) from coq_makefile to master:

Kind: feature.

Relates to #7740 and #7722.

The behaviour of coq_makefile regarding DESTDIR is somehow confusing (as seen in the related bug reports above). The “usual” set-up in Linux seems to be:

The COQMF_WINDRIVE parts feels like a hack and is currently undocumented. This PR provides an alternative way (without breaking the previous way):

Being able to set up the installation directory is especially important when using programs like esy, in which different Coq installation can be shared among repositories: esy installs Coq libraries into their own directory, relying on the COQPATH mechanism to link everything back together. By forcing the installation to ${COQLIB}/user-contrib, coq_makefile is installing files in a shared folder, which breaks esy’s invariants required for replication.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:24):

Zimmi48 updated PR #12397 Fix #12280: do not use xindy to avoid build failures on some machines. from do-not-use-xindy to master:

Kind: documentation infrastructure.

Fixes / closes #12280.

The build still goes through and the index still looks fine. Since the manual is entirely written in English, I think there is no issue with using makeindex instead.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:37):

Zimmi48 milestoned Issue #12411 Add support for CoqMakefile.local-late:

This allows users to write rules that depend on variables such as
VOFILES and VDFILE, which is essential in some of my use-cases (for
example, to properly handle seamless version switching, I need to make
all of the .vo files depend on a file where I record the version of Coq
being used).

Fixes #10912

Kind: feature / infrastructure.

Does this qualify for 8.12 / 8.12+beta1?

view this post on Zulip Coq Github Bot (May 26 2020 at 10:39):

SkySkimmer submitted PR Review for #12410 dev/tools/make-changelog.sh now asks about fixed bugs.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:39):

SkySkimmer assigned PR #12410 dev/tools/make-changelog.sh now asks about fixed bugs to SkySkimmer.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:40):

Zimmi48 submitted PR Review for #12410 dev/tools/make-changelog.sh now asks about fixed bugs.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:40):

Zimmi48 created PR Review Comment on #12410 dev/tools/make-changelog.sh now asks about fixed bugs:

Thanks for the example :) but we usually do not introduce changelog entries for purely internal PRs.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:40):

SkySkimmer pushed 2 commits to branch master. Commits by JasonGross (1) and SkySkimmer (1).

view this post on Zulip Coq Github Bot (May 26 2020 at 10:40):

SkySkimmer closed Issue #12386 dev/tools/make-changelog.sh should automatically handle bugs fixed by the PR:

I'd like dev/tools/make-changelog.sh to also ask me if the PR fixes any bugs (say, a space-separated list of numbers), and it should automatically generate the "Fixes" part of the changelog as well

view this post on Zulip Coq Github Bot (May 26 2020 at 10:40):

SkySkimmer merged PR #12410 dev/tools/make-changelog.sh now asks about fixed bugs.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:41):

coqbot milestoned Issue #12386 dev/tools/make-changelog.sh should automatically handle bugs fixed by the PR:

I'd like dev/tools/make-changelog.sh to also ask me if the PR fixes any bugs (say, a space-separated list of numbers), and it should automatically generate the "Fixes" part of the changelog as well

view this post on Zulip Coq Github Bot (May 26 2020 at 10:45):

Zimmi48 milestoned Issue #12410 dev/tools/make-changelog.sh now asks about fixed bugs (assigned to SkySkimmer):

Fixes #12386

Kind: infrastructure.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:45):

Zimmi48 demilestoned Issue #12410 dev/tools/make-changelog.sh now asks about fixed bugs (assigned to SkySkimmer):

Fixes #12386

Kind: infrastructure.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:46):

Zimmi48 milestoned Issue #12386 dev/tools/make-changelog.sh should automatically handle bugs fixed by the PR:

I'd like dev/tools/make-changelog.sh to also ask me if the PR fixes any bugs (say, a space-separated list of numbers), and it should automatically generate the "Fixes" part of the changelog as well

view this post on Zulip Coq Github Bot (May 26 2020 at 10:46):

Zimmi48 demilestoned Issue #12386 dev/tools/make-changelog.sh should automatically handle bugs fixed by the PR:

I'd like dev/tools/make-changelog.sh to also ask me if the PR fixes any bugs (say, a space-separated list of numbers), and it should automatically generate the "Fixes" part of the changelog as well

view this post on Zulip Coq Github Bot (May 26 2020 at 10:47):

ejgallego labeled Issue #11244 Report on the 8.8 to 8.10 compatibility of packages in coq-contribs:

Hi, here are a few (partial) comments about porting developments from Coq 8.8 to 8.10 (continuing #8793).

Globally, it takes time but it works relatively well, with helpful messages or tools. It was painful in some specific cases though.

Deprecation of alias

The script replace-notations.py was very good. A posteriori, the warning could have been improved to report about the full name (including its dirpath) and not only the basename.

Removal of Implicit Arguments and Arguments Scope

This is rather straightforward. A posteriori, that would somehow have been good to have a script in the style of replace-notations.py.

Move from .ml4 to .mlg

The renaming and insertion of curly brackets is easy, but coqpp seems to suffer from being a bit "young" and not helpful in case of problems. To fix syntax errors, I have to look at the code of coqpp to know what to do. Also, entries such as INT and LIDENT are not supported anymore and cause the brutal death of coqpp. (I still have to find what are the replacements...) Location reporting does not seem always accurate.

Removal of Quote

I'll probably add it as a package (which requires less thinking than adapting).

Removal of template polymorphism in sections

Moving the type outside the section is canonical.

Unidentified problems with import of coercions

Problems with imports are the most difficult to solve: need to compare the old and new scripts, and sometimes not at the place where it starts to fail.

Miscellaneous regressions

Warnings

fourier

The upgrade works rather well by using lra. The difficulties are that Require Import Fourier includes some constants and scopes which have to be expressed differently (e.g. using lemmas from Reals).

omega/romega

The move to lia works pretty well. A painful consequence has been to control the section variables used by omega/lia since this affects the form of a theorem at the end of the section.

Primitive string parsers

Adding Import Coq.Strings.String.string works well.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:49):

Zimmi48 submitted PR Review for #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:49):

Zimmi48 created PR Review Comment on #12396 Release notes 8.12:

Making them subsections doesn't make them appear in the TOC in the left-bar (too many levels) and I tried both and I prefer the appearance that the current state results in.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:50):

Zimmi48 submitted PR Review for #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:50):

Zimmi48 created PR Review Comment on #12396 Release notes 8.12:

Note that there will be a summary written by @mattam82 with some direct links to a selection of changelog entries.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:51):

Zimmi48 submitted PR Review for #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:51):

Zimmi48 created PR Review Comment on #12396 Release notes 8.12:

Agreed.

view this post on Zulip Coq Github Bot (May 26 2020 at 10:55):

Zimmi48 updated PR #12396 Release notes 8.12 from release-notes-8.12 to master:

Kind: documentation

This PR consolidates the release notes for 8.12+beta1. It should be a good basis on which @mattam82 can work to prepare a summary of the changes.

The consolidation was initially done thanks to the dev/tools/generate-release-changelog.sh script but I fixed a lot of typos and improved the wording or the links to the doc here and there.

More importantly, I've also reordered the entries by type of change (the order is Changed, Removed, Deprecated, Added, Fixed). I did this because I feel like this makes reading the changelog much easier when there are many entries. The order is chosen so that breaking changes are shown first. If people like this ordering, then we can adapt the changelog infrastructure so that it is automatically sorted like this next time.

I also introduced some new categories: Options, flags and attributes + Commands instead of Commands and options because this category was very long; Reals library (split out of Standard Library because there was much content about this); Reference manual to document all the recent important changes that it received.

The last commit introduces changelog entries about the reference manual (cc @jfehrle).

view this post on Zulip Coq Github Bot (May 26 2020 at 11:04):

Zimmi48 updated PR #12391 Backport batch of PRs to v8.12. from backport-v8.12 to v8.12.

view this post on Zulip Coq Github Bot (May 26 2020 at 11:05):

ejgallego opened Issue #12413 [lexer] Expose comments as tokens:

It would be nice to have a COMMENT token type, so users of the lexer can actually see the comments in streams. This has been requested a few times, for example:

Even if some of these requests would require more than extending the lexer, this would be a good first step. OCaml does something similar, see COMMENTS token in https://github.com/ocaml/ocaml/blob/4c24dca92ad684494e9d186412a52be3983d909a/parsing/parser.mly#L704

view this post on Zulip Coq Github Bot (May 26 2020 at 11:05):

ejgallego labeled Issue #12413 [lexer] Expose comments as tokens:

It would be nice to have a COMMENT token type, so users of the lexer can actually see the comments in streams. This has been requested a few times, for example:

Even if some of these requests would require more than extending the lexer, this would be a good first step. OCaml does something similar, see COMMENTS token in https://github.com/ocaml/ocaml/blob/4c24dca92ad684494e9d186412a52be3983d909a/parsing/parser.mly#L704

view this post on Zulip Coq Github Bot (May 26 2020 at 11:05):

ejgallego labeled Issue #12413 [lexer] Expose comments as tokens:

It would be nice to have a COMMENT token type, so users of the lexer can actually see the comments in streams. This has been requested a few times, for example:

Even if some of these requests would require more than extending the lexer, this would be a good first step. OCaml does something similar, see COMMENTS token in https://github.com/ocaml/ocaml/blob/4c24dca92ad684494e9d186412a52be3983d909a/parsing/parser.mly#L704

view this post on Zulip Coq Github Bot (May 26 2020 at 11:05):

ejgallego labeled Issue #12413 [lexer] Expose comments as tokens:

It would be nice to have a COMMENT token type, so users of the lexer can actually see the comments in streams. This has been requested a few times, for example:

Even if some of these requests would require more than extending the lexer, this would be a good first step. OCaml does something similar, see COMMENTS token in https://github.com/ocaml/ocaml/blob/4c24dca92ad684494e9d186412a52be3983d909a/parsing/parser.mly#L704

view this post on Zulip Coq Github Bot (May 26 2020 at 11:05):

ejgallego labeled Issue #12413 [lexer] Expose comments as tokens:

It would be nice to have a COMMENT token type, so users of the lexer can actually see the comments in streams. This has been requested a few times, for example:

Even if some of these requests would require more than extending the lexer, this would be a good first step. OCaml does something similar, see COMMENTS token in https://github.com/ocaml/ocaml/blob/4c24dca92ad684494e9d186412a52be3983d909a/parsing/parser.mly#L704

view this post on Zulip Coq Github Bot (May 26 2020 at 11:05):

ejgallego labeled Issue #12413 [lexer] Expose comments as tokens:

It would be nice to have a COMMENT token type, so users of the lexer can actually see the comments in streams. This has been requested a few times, for example:

Even if some of these requests would require more than extending the lexer, this would be a good first step. OCaml does something similar, see COMMENTS token in https://github.com/ocaml/ocaml/blob/4c24dca92ad684494e9d186412a52be3983d909a/parsing/parser.mly#L704

view this post on Zulip Coq Github Bot (May 26 2020 at 11:15):

Zimmi48 assigned [PR #12399 Remove the prolog tactic.](https://github.com/coq/coq/pull/12399 to Zimmi48.

view this post on Zulip Coq Github Bot (May 26 2020 at 12:17):

Janno opened Issue #12414 Universe with Prop <= i not minimized to i := Set, resulting in costly, unconstrained universes:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

The following snippet fails at the last Check invocation.

Set Universe Polymorphism.
Set Printing Universes.
Inductive list {T} : Type := | cons (t : T) : list -> list. (* who needs nil anyway? *)
Arguments list : clear implicits.

Fixpoint map {A B} (f: A -> B) (l : list A) : list B :=
  let '(cons t l) := l in cons (f t) (map f l).
Check map@{_ _}.
(* Two universes, as expected. *)

Definition map_Set {A B : Set} := @map A B.
Check map_Set@{}.
(* Universes minimized away, as expected. *)

Definition map_Prop {A B : Prop} := @map A B.
Check map_Prop@{}.              (* Fails! *)
(* Universes *not* minimized away! Confusion abound! *)

While this is not wrong, it essentially means that users pay a very heavy and unnecessary price for using universe polymorphism and later instantiating the definitions with propositions. It is very easy to amass thousands and sometimes tens of thousands of universes in a single definition and in my Mtac2 use cases most of them would disappear since they correspond to types instantiated with propositions.

I am reporting this issue to make sure that the feature request—or should it be called a bug fix?—is not forgotten. (My initial "bug report" happened verbally during POPL.)

There have been two attempts at fixing this (#9343, #10331) but they have both been closed.

<!-- If you can, it's helpful to provide self-contained example of some code
that reproduces the bug. If not, a link to a larger example is also helpful. -->

Coq Version

master, but to my knowledge this behaviour was never different in earlier Coq version.

<!-- You can get this information by running coqtop -v. If relevant, please
also include your operating system. -->

view this post on Zulip Coq Github Bot (May 26 2020 at 12:17):

Janno labeled Issue #12414 Universe with Prop <= i not minimized to i := Set, resulting in costly, unconstrained universes:

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

The following snippet fails at the last Check invocation.

Set Universe Polymorphism.
Set Printing Universes.
Inductive list {T} : Type := | cons (t : T) : list -> list. (* who needs nil anyway? *)
Arguments list : clear implicits.

Fixpoint map {A B} (f: A -> B) (l : list A) : list B :=
  let '(cons t l) := l in cons (f t) (map f l).
Check map@{_ _}.
(* Two universes, as expected. *)

Definition map_Set {A B : Set} := @map A B.
Check map_Set@{}.
(* Universes minimized away, as expected. *)

Definition map_Prop {A B : Prop} := @map A B.
Check map_Prop@{}.              (* Fails! *)
(* Universes *not* minimized away! Confusion abound! *)

While this is not wrong, it essentially means that users pay a very heavy and unnecessary price for using universe polymorphism and later instantiating the definitions with propositions. It is very easy to amass thousands and sometimes tens of thousands of universes in a single definition and in my Mtac2 use cases most of them would disappear since they correspond to types instantiated with propositions.

I am reporting this issue to make sure that the feature request—or should it be called a bug fix?—is not forgotten. (My initial "bug report" happened verbally during POPL.)

There have been two attempts at fixing this (#9343, #10331) but they have both been closed.

<!-- If you can, it's helpful to provide self-contained example of some code
that reproduces the bug. If not, a link to a larger example is also helpful. -->

Coq Version

master, but to my knowledge this behaviour was never different in earlier Coq version.

<!-- You can get this information by running coqtop -v. If relevant, please
also include your operating system. -->

view this post on Zulip Coq Github Bot (May 26 2020 at 13:17):

Zimmi48 assigned [PR #12397 Fix #12280: do not use xindy to avoid build failures on some machines.](https://github.com/coq/coq/pull/12397 to cpitclaudel.

view this post on Zulip Coq Github Bot (May 26 2020 at 13:40):

Zimmi48 opened PR #12415 Carefully select which versions of add-ons are included in the Windows installer. from smart-pinning to v8.12:

Cf. #12360.

@Janno: Should mtac2 get a new master-8.12 branch? The start point could be mtac2/mtac2@62071fe76d05e7d1bd43583514ad498102b556bd.

view this post on Zulip Coq Github Bot (May 26 2020 at 13:40):

Zimmi48 milestoned Issue #12415 Carefully select which versions of add-ons are included in the Windows installer.

Cf. #12360.

@Janno: Should mtac2 get a new master-8.12 branch? The start point could be mtac2/mtac2@62071fe76d05e7d1bd43583514ad498102b556bd.

view this post on Zulip Coq Github Bot (May 26 2020 at 13:40):

Zimmi48 edited PR #12415 [v8.12] Carefully select which versions of add-ons are included in the Windows installer. from smart-pinning to v8.12:

Cf. #12360.

@Janno: Should mtac2 get a new master-8.12 branch? The start point could be mtac2/mtac2@62071fe76d05e7d1bd43583514ad498102b556bd.

view this post on Zulip Coq Github Bot (May 26 2020 at 13:42):

Zimmi48 edited PR #12415 [v8.12] Carefully select which versions of add-ons are included in the Windows installer. from smart-pinning to v8.12:

Cf. #12360.

@Janno: Should mtac2 get a new master-8.12 branch? The start point could be mtac2/mtac2@62071fe76d05e7d1bd43583514ad498102b556bd.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:11):

Zimmi48 updated PR #12415 [v8.12] Carefully select which versions of add-ons are included in the Windows installer. from smart-pinning to v8.12:

Cf. #12360.

@Janno: Should mtac2 get a new master-8.12 branch? The start point could be mtac2/mtac2@62071fe76d05e7d1bd43583514ad498102b556bd.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:15):

Zimmi48 updated PR #12391 Backport batch of PRs to v8.12. from backport-v8.12 to v8.12.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:15):

Zimmi48 pushed 11 commits to branch v8.12. Commits by Zimmi48 (7), JasonGross (1), gasparattila (1) and others (2).

view this post on Zulip Coq Github Bot (May 26 2020 at 14:16):

shiatsumat closed without merge PR #12404 trim new lines in ssreflect-proof-language.rst.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:26):

Zimmi48 submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:26):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

OK, but then the following becomes confusing:

The documentation also describes the following as tactics because they can generally be used anywhere a tactic can even though they fit into other levels of ltac_expr:
- ...
- l1_tactics are: first, solve, idtac, fail and gfail as well as match, match goal and their lazymatch and multimatch variants.

If the wording could be tweaked to make it a tad less confusing, it would be better. Not a big deal though.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:27):

Zimmi48 submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:27):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

In this case, I'd bet that the redundancy would have been confusing to the reader :wink:

view this post on Zulip Coq Github Bot (May 26 2020 at 14:28):

gares submitted PR Review for #12389 Small coq_makefile improvement.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:32):

gares submitted PR Review for #12412 Reduce options passed to workers.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:33):

gares assigned PR #12412 Reduce options passed to workers to gares.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:58):

Zimmi48 submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:58):

Zimmi48 submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:58):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

The way you've integrated this change will rebasing looks quite odd. I think the note should be below the one on precedence, which you cut in the middle.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:58):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

It looks like the actual error message is No applicable tactic.

view this post on Zulip Coq Github Bot (May 26 2020 at 14:58):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

Should there be a __i on the tacn line?

view this post on Zulip Coq Github Bot (May 26 2020 at 14:58):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

   :tacn:`fail` and :tacn:`gfail` are :token:`l1_tactic`\s.

view this post on Zulip Coq Github Bot (May 26 2020 at 15:44):

Mbodin updated PR #12389 Small coq_makefile improvement. (assigned to gares) from coq_makefile to master:

Kind: feature.

Relates to #7740 and #7722.

The behaviour of coq_makefile regarding DESTDIR is somehow confusing (as seen in the related bug reports above). The “usual” set-up in Linux seems to be:

The COQMF_WINDRIVE parts feels like a hack and is currently undocumented. This PR provides an alternative way (without breaking the previous way):

Being able to set up the installation directory is especially important when using programs like esy, in which different Coq installation can be shared among repositories: esy installs Coq libraries into their own directory, relying on the COQPATH mechanism to link everything back together. By forcing the installation to ${COQLIB}/user-contrib, coq_makefile is installing files in a shared folder, which breaks esy’s invariants required for replication.

view this post on Zulip Coq Github Bot (May 26 2020 at 15:46):

Mbodin edited PR #12389 Small coq_makefile improvement. (assigned to gares) from coq_makefile to master:

Kind: feature.

Relates to #7740 and #7722.

The behaviour of coq_makefile regarding DESTDIR is somehow confusing (as seen in the related bug reports above). The “usual” set-up in Linux seems to be:

The COQMF_WINDRIVE parts feels like a hack and is currently undocumented. This PR provides an alternative way (without breaking the previous way):

Being able to set up the installation directory is especially important when using programs like esy, in which different Coq installation can be shared among repositories: esy installs Coq libraries into their own directory, relying on the COQPATH mechanism to link everything back together. By forcing the installation to ${COQLIB}/user-contrib, coq_makefile is installing files in a shared folder, which breaks esy’s invariants required for replication.

view this post on Zulip Coq Github Bot (May 26 2020 at 15:53):

Mbodin updated PR #12389 Small coq_makefile improvement. (assigned to gares) from coq_makefile to master:

Kind: feature.

Relates to #7740 and #7722.

The behaviour of coq_makefile regarding DESTDIR is somehow confusing (as seen in the related bug reports above). The “usual” set-up in Linux seems to be:

The COQMF_WINDRIVE parts feels like a hack and is currently undocumented. This PR provides an alternative way (without breaking the previous way):

Being able to set up the installation directory is especially important when using programs like esy, in which different Coq installation can be shared among repositories: esy installs Coq libraries into their own directory, relying on the COQPATH mechanism to link everything back together. By forcing the installation to ${COQLIB}/user-contrib, coq_makefile is installing files in a shared folder, which breaks esy’s invariants required for replication.

view this post on Zulip Coq Github Bot (May 26 2020 at 16:29):

ejgallego updated PR #12393 [declare] Miscellaneous nits from my main dev tree from declare+misc9 to master:

Some small commits from my dev tree, I think these are for the most part quite trivial, tho we reduce the internal API a bit.

Depends on #12357 [no point in having to do a rebase]

view this post on Zulip Coq Github Bot (May 26 2020 at 16:29):

ejgallego has marked PR #12393 as ready for review.

view this post on Zulip Coq Github Bot (May 26 2020 at 16:29):

ejgallego requested vernac-maintainers for a review on PR #12393 [declare] Miscellaneous nits from my main dev tree.

view this post on Zulip Coq Github Bot (May 26 2020 at 16:29):

ejgallego milestoned Issue #12393 [declare] Miscellaneous nits from my main dev tree:

Some small commits from my dev tree, I think these are for the most part quite trivial, tho we reduce the internal API a bit.

Depends on #12357 [no point in having to do a rebase]

view this post on Zulip Coq Github Bot (May 26 2020 at 16:29):

ejgallego edited PR #12393 [declare] Miscellaneous nits from my main dev tree from declare+misc9 to master:

Some small commits from my dev tree, I think these are for the most part quite trivial, tho we reduce the internal API a bit.

view this post on Zulip Coq Github Bot (May 26 2020 at 17:21):

VizorKit opened Issue #12416 Creating a new Extraction "language"? [kind: question]

[kind: question]

I am trying to create my own extractor to a different output than Scheme, OCaml, C, and Haskell. I am sorry to even bother anyone with this question. But there doesn't seem to be a lot of documentation on how the original creators did so. Any direction at all would be helpful, as far as where to look at someones previous work. Any documentation that might be helpful with contributing to Coq. Etc.

Thanks.

view this post on Zulip Coq Github Bot (May 26 2020 at 17:28):

Zimmi48 labeled Issue #12416 Creating a new Extraction "language"? [kind: question]

[kind: question]

I am trying to create my own extractor to a different output than Scheme, OCaml, C, and Haskell. I am sorry to even bother anyone with this question. But there doesn't seem to be a lot of documentation on how the original creators did so. Any direction at all would be helpful, as far as where to look at someones previous work. Any documentation that might be helpful with contributing to Coq. Etc.

Thanks.

view this post on Zulip Coq Github Bot (May 26 2020 at 17:28):

Zimmi48 labeled Issue #12416 Creating a new Extraction "language"? [kind: question]

[kind: question]

I am trying to create my own extractor to a different output than Scheme, OCaml, C, and Haskell. I am sorry to even bother anyone with this question. But there doesn't seem to be a lot of documentation on how the original creators did so. Any direction at all would be helpful, as far as where to look at someones previous work. Any documentation that might be helpful with contributing to Coq. Etc.

Thanks.

view this post on Zulip Coq Github Bot (May 26 2020 at 17:32):

VizorKit edited Issue #12416 Creating a new Extraction "language"?

[kind: question]

I am trying to create my own extractor to a different output than Scheme, OCaml, C, and Haskell. I am sorry to even bother anyone with this question. But there doesn't seem to be a lot of documentation on how the original creators did so. Any direction at all would be helpful, as far as where to look at someones previous work. Any documentation that might be helpful with contributing to Coq. Etc.

Thanks.

view this post on Zulip Coq Github Bot (May 26 2020 at 17:32):

VizorKit edited Issue #12416 Creating a new Extraction "language"?

I am trying to create my own extractor to a different output than Scheme, OCaml, C, and Haskell. I am sorry to even bother anyone with this question. But there doesn't seem to be a lot of documentation on how the original creators did so. Any direction at all would be helpful, as far as where to look at someones previous work. Any documentation that might be helpful with contributing to Coq. Etc.

Thanks.

view this post on Zulip Coq Github Bot (May 26 2020 at 17:53):

jfehrle submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 17:53):

jfehrle created PR Review Comment on #12103 Convert Ltac chapter to prodn:

That message is already documented so it can't be repeated here.

view this post on Zulip Coq Github Bot (May 26 2020 at 18:06):

bfbonatto opened Issue #12417 Encountered an Anomaly when defining a Function:

Description of the problem

Hi, I am trying to define a function with a non-standard recursion pattern and encountered an
anomaly on the sum_total function: ' Anomaly "Uncaught exception Retyping.RetypeError(0)." '

Require Import List.
Require Export PeanoNat.
Require Export Omega.
Require Export CpdtTactics.
Require Import FunInd.
Require Import Recdef.

Notation "A :: B" := (cons A B).
Notation "[]" := nil.
Notation "[[ A ]]" := (A :: nil).

Inductive tm :=
| E: nat -> tm
| L: list tm -> tm.

Definition T := list tm.

Fixpoint max_list (p: nat) (l: list nat) : nat :=
match l with
| [] => p
| n :: l' => max_list (Init.Nat.max n p) l'
end.

Fixpoint depth (t: tm) : nat :=
match t with
| E _ => 0
| L l => 1 + max_list 0 (map depth l)
end.

Fixpoint sum_depth (l: T) : nat :=
match l with
| [] => 0
| n :: l' => (depth n) + sum_depth l'
end.

Definition sum_depth_order (t1 t2 : T) :=
sum_depth t1 < sum_depth t2.

Hint Constructors Acc.

Lemma sum_depth_order_wf' : forall d l, sum_depth l <= d ->
Acc sum_depth_order l.
Proof.
unfold sum_depth_order. induction d; intros.

- assert (sum_depth l = 0). omega.
apply Acc_intro. intros. omega.

- apply Acc_intro. intros. assert (sum_depth y <= d). omega.
apply IHd. auto.
Defined.

Theorem sum_depth_order_wf : well_founded sum_depth_order.
Proof.
unfold well_founded. unfold depth_order. intros.
eapply sum_depth_order_wf'. eauto.
Defined.

Function sum_total (l: T) {wf sum_depth l} : nat :=
match l with
| [] => 0
| t :: l' =>
(match t with
| E n => n
| L li => sum_total li
end) + sum_total l'
end.

Coq Version

8.10.1 on MacOs Mojave 10.14.5

view this post on Zulip Coq Github Bot (May 26 2020 at 18:24):

ejgallego labeled Issue #12417 Encountered an Anomaly when defining a Function:

Description of the problem

Hi, I am trying to define a function with a non-standard recursion pattern and encountered an
anomaly on the sum_total function: ' Anomaly "Uncaught exception Retyping.RetypeError(0)." '

Require Import List.
Require Export PeanoNat.
Require Export Omega.
Require Export CpdtTactics.
Require Import FunInd.
Require Import Recdef.

Notation "A :: B" := (cons A B).
Notation "[]" := nil.
Notation "[[ A ]]" := (A :: nil).

Inductive tm :=
| E: nat -> tm
| L: list tm -> tm.

Definition T := list tm.

Fixpoint max_list (p: nat) (l: list nat) : nat :=
match l with
| [] => p
| n :: l' => max_list (Init.Nat.max n p) l'
end.

Fixpoint depth (t: tm) : nat :=
match t with
| E _ => 0
| L l => 1 + max_list 0 (map depth l)
end.

Fixpoint sum_depth (l: T) : nat :=
match l with
| [] => 0
| n :: l' => (depth n) + sum_depth l'
end.

Definition sum_depth_order (t1 t2 : T) :=
sum_depth t1 < sum_depth t2.

Hint Constructors Acc.

Lemma sum_depth_order_wf' : forall d l, sum_depth l <= d ->
Acc sum_depth_order l.
Proof.
unfold sum_depth_order. induction d; intros.

- assert (sum_depth l = 0). omega.
apply Acc_intro. intros. omega.

- apply Acc_intro. intros. assert (sum_depth y <= d). omega.
apply IHd. auto.
Defined.

Theorem sum_depth_order_wf : well_founded sum_depth_order.
Proof.
unfold well_founded. unfold depth_order. intros.
eapply sum_depth_order_wf'. eauto.
Defined.

Function sum_total (l: T) {wf sum_depth l} : nat :=
match l with
| [] => 0
| t :: l' =>
(match t with
| E n => n
| L li => sum_total li
end) + sum_total l'
end.

Coq Version

8.10.1 on MacOs Mojave 10.14.5

view this post on Zulip Coq Github Bot (May 26 2020 at 19:12):

MSoegtropIMC updated PR #12186 CReal: changed epsilon for modulus of convergence from 1/n to 1/2^n from creal-new-modulus to master:

This PR changes the epsilon in the definition of the modulus of convergence for CReal from 1/n to 1/2^n. This avoids the issue that in practical high precision computations, even as binary integer n would be quite large (say 2^1000000), although quadratically convergent algorithms might need only a few 10 iterations to reach such a precision.

This is work in progress (right now I just did the main file ConstructiveCauchyReals.v).

@VincentSe : some things I think I should change:

view this post on Zulip Coq Github Bot (May 26 2020 at 21:10):

Zimmi48 submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 21:10):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

Right. But you could remove this incorrect one. And you could also refer the already documented message as is done here: https://github.com/coq/coq/blob/master/doc/sphinx/language/core/basic.rst#attributes (except that this example is referring to a warning). But that's up to you of course!

view this post on Zulip Coq Github Bot (May 26 2020 at 21:23):

jfehrle submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 21:23):

jfehrle created PR Review Comment on #12103 Convert Ltac chapter to prodn:

Then [> ] is a weird exception. [> idtac "x"] only works if there's one goal, [> idtac "y"; idtac "z" ] only works if there are 2. Consistency suggests [> ] should work only if there are zero goals.

If that's a really important use case maybe it's worth mentioning in the doc. Isn't there a construction using numgoals that is more obvious?

In this case, I'd bet that the redundancy would have been confusing to the reader

I disagree. It should be obvious to any reader that {? {? foo } } is the same as {? foo }. Determining whether for_each_goalis optional while reading the tactic line requires reading 2 lines of the prodn. Showing in the tactic is easier to read. But I'd only do it if we document [> ].

view this post on Zulip Coq Github Bot (May 26 2020 at 21:25):

jfehrle updated PR #12103 Convert Ltac chapter to prodn (assigned to Zimmi48) from prodn_ltac to master:

A strategy question for now, don't read more than you have to.

I think the two-page long grammar in the Syntax section doesn't work.

I think I can live with making all the tacticals as tacn::, but we may need to add comments on them saying which ltac_expr* they're associated with this since that has some effect on how the expression is interpreted (precedence).

Then there would be 2 possibilities for that syntax block:

I'd go for the first option. Also, I need to make sure I understand how the precedence works.

Your thoughts?

Fix #11932

view this post on Zulip Coq Github Bot (May 26 2020 at 21:26):

Zimmi48 submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 21:26):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

You are getting confused. All your examples work only if there are exactly one goal (because there is no |).

view this post on Zulip Coq Github Bot (May 26 2020 at 21:27):

Zimmi48 submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 21:27):

Zimmi48 created PR Review Comment on #12103 Convert Ltac chapter to prodn:

In particular, there is no weird exception.

view this post on Zulip Coq Github Bot (May 26 2020 at 21:33):

jfehrle edited PR Review Comment on #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 21:41):

jfehrle submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 26 2020 at 21:41):

jfehrle created PR Review Comment on #12103 Convert Ltac chapter to prodn:

I had a typo, should have been [> idtac "x" | idtac "y"].

Then we need to reword "the construct fails if the number of specified {? @ltac_expr } is not the same as the number of focused goals." with the less aesthetic

"... as the number of "|" plus one."

view this post on Zulip Coq Github Bot (May 26 2020 at 21:59):

jfehrle submitted PR Review for #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 26 2020 at 21:59):

jfehrle created PR Review Comment on #12396 Release notes 8.12:

Making them subsections doesn't make them appear in the TOC in the left-bar (too many levels) and I tried both and I prefer the appearance that the current state results in.

We should figure out, though not in this PR, a better way to handle this because the issue arises in other long chapters or sections. I expect the TOC should be configurable somehow. Manually adding hyperlinks at the beginning of the section is easy enough, but isn't self-maintaining. There ought to be a directive to make it self maintaining. WDYT?

view this post on Zulip Coq Github Bot (May 26 2020 at 23:49):

satnam6502 opened Issue #12418 File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed.

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I get the following error message:

"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."

I suspect I have done something wrong :-(

Repo:

$ git clone https://github.com/satnam6502/oak-hardware
$ git checkout 38971a7d0f8aa04b6fa4e21d1dfda3990ecf2c66
$ cd oak-hardware/cava/cava
$ make coq
coq_makefile -f _CoqProject -o Makefile.coq
/Library/Developer/CommandLineTools/usr/bin/make -f Makefile.coq
COQDEP VFILES
*** Warning: in file Cava/Arrow/Instances/Netlist.v,
    required library Netlist matches several files in path
    (found Netlist.v in Cava/Arrow/Instances and Cava; used the latter)
COQC Cava/BitArithmetic.v
COQC Cava/Signal.v
COQC Cava/Types.v
COQC Cava/Netlist.v
COQC Cava/Monad/Cava.v
COQC Cava/Monad/Combinators.v
COQC Cava/Monad/UnsignedAdders.v
COQC Cava/Monad/XilinxAdder.v
COQC Cava/Arrow/Arrow.v
COQC Cava/Arrow/Instances/Constructive.v
COQC Cava/Arrow/Instances/Combinational.v
COQC Cava/Arrow/Instances/Netlist.v
File "./Cava/Arrow/Instances/Netlist.v", line 111, characters 2-1820:
Error:
Anomaly
"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."
Please report at http://coq.inria.fr/bugs/.

Coq Version

$ coqtop -v
The Coq Proof Assistant, version 8.11.0 (January 2020)
compiled on Jan 27 2020 17:46:49 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 27 2020 at 02:20):

JasonGross submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 27 2020 at 02:20):

JasonGross created PR Review Comment on #12103 Convert Ltac chapter to prodn:

The sentence as stated is true; you just need to be aware of the fact that {? @ltac_expr } is allowed to be empty, so the number of {? @ltac_expr } is not the same as the number of @ltac_expr in some cases. Perhaps this is worth noting? Note also that this correspondence breaks down if .. appears in the construction.

view this post on Zulip Coq Github Bot (May 27 2020 at 02:24):

JasonGross submitted PR Review for #12103 Convert Ltac chapter to prodn.

view this post on Zulip Coq Github Bot (May 27 2020 at 02:24):

JasonGross created PR Review Comment on #12103 Convert Ltac chapter to prodn:

Note also that, e.g., [ > | | | ] is valid, and I use this form of the construction sometimes in preference to numgoals with guard, as it's much shorter (and also more version-independent; I seem to recall guard having some weird edge cases around having 0 goals back when it was first introduced).

view this post on Zulip Coq Github Bot (May 27 2020 at 06:16):

MSoegtropIMC updated PR #12186 CReal: changed epsilon for modulus of convergence from 1/n to 1/2^n from creal-new-modulus to master:

This PR changes the epsilon in the definition of the modulus of convergence for CReal from 1/n to 1/2^n. This avoids the issue that in practical high precision computations, even as binary integer n would be quite large (say 2^1000000), although quadratically convergent algorithms might need only a few 10 iterations to reach such a precision.

This is work in progress (right now I just did the main file ConstructiveCauchyReals.v).

@VincentSe : some things I think I should change:

view this post on Zulip Coq Github Bot (May 27 2020 at 08:00):

VincentSe updated PR #12409 Parametric rings from ParametricRings to master:

Kind: feature

Make Add Ring parametric, so that we can register families of rings like
Add Parametric Ring CRRing (R : ConstructiveReals) : (CRisRing R).

view this post on Zulip Coq Github Bot (May 27 2020 at 08:28):

ppedrot milestoned Issue #12419 Various cleanups in eauto:

Nothing involved, this factorizes code and enforces a few static invariants on the way.

I had a bench just in case but it doesn't show anything except noise.

view this post on Zulip Coq Github Bot (May 27 2020 at 08:28):

ppedrot opened PR #12419 Various cleanups in eauto from cleanup-eauto to master:

Nothing involved, this factorizes code and enforces a few static invariants on the way.

I had a bench just in case but it doesn't show anything except noise.

view this post on Zulip Coq Github Bot (May 27 2020 at 08:28):

ppedrot requested tactics-maintainers for a review on PR #12419 Various cleanups in eauto.

view this post on Zulip Coq Github Bot (May 27 2020 at 08:58):

ejgallego:

view this post on Zulip Coq Github Bot (May 27 2020 at 09:02):

ejgallego labeled Issue #12418 File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed.

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I get the following error message:

"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."

I suspect I have done something wrong :-(

Repo:

$ git clone https://github.com/satnam6502/oak-hardware
$ git checkout 38971a7d0f8aa04b6fa4e21d1dfda3990ecf2c66
$ cd oak-hardware/cava/cava
$ make coq
coq_makefile -f _CoqProject -o Makefile.coq
/Library/Developer/CommandLineTools/usr/bin/make -f Makefile.coq
COQDEP VFILES
*** Warning: in file Cava/Arrow/Instances/Netlist.v,
    required library Netlist matches several files in path
    (found Netlist.v in Cava/Arrow/Instances and Cava; used the latter)
COQC Cava/BitArithmetic.v
COQC Cava/Signal.v
COQC Cava/Types.v
COQC Cava/Netlist.v
COQC Cava/Monad/Cava.v
COQC Cava/Monad/Combinators.v
COQC Cava/Monad/UnsignedAdders.v
COQC Cava/Monad/XilinxAdder.v
COQC Cava/Arrow/Arrow.v
COQC Cava/Arrow/Instances/Constructive.v
COQC Cava/Arrow/Instances/Combinational.v
COQC Cava/Arrow/Instances/Netlist.v
File "./Cava/Arrow/Instances/Netlist.v", line 111, characters 2-1820:
Error:
Anomaly
"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."
Please report at http://coq.inria.fr/bugs/.

Coq Version

$ coqtop -v
The Coq Proof Assistant, version 8.11.0 (January 2020)
compiled on Jan 27 2020 17:46:49 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 27 2020 at 09:42):

ejgallego assigned [PR #12408 Fix output tests for location errors when running in async mode.](https://github.com/coq/coq/pull/12408 to ejgallego.

view this post on Zulip Coq Github Bot (May 27 2020 at 09:43):

ejgallego submitted PR Review for #12408 Fix output tests for location errors when running in async mode.

view this post on Zulip Coq Github Bot (May 27 2020 at 09:45):

ejgallego pushed 2 commits to branch master. Commits by Zimmi48 (1) and ejgallego (1).

view this post on Zulip Coq Github Bot (May 27 2020 at 09:45):

ejgallego merged PR #12408 Fix output tests for location errors when running in async mode.

view this post on Zulip Coq Github Bot (May 27 2020 at 09:50):

ejgallego labeled Issue #12418 File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed.

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I get the following error message:

"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."

I suspect I have done something wrong :-(

Repo:

$ git clone https://github.com/satnam6502/oak-hardware
$ git checkout 38971a7d0f8aa04b6fa4e21d1dfda3990ecf2c66
$ cd oak-hardware/cava/cava
$ make coq
coq_makefile -f _CoqProject -o Makefile.coq
/Library/Developer/CommandLineTools/usr/bin/make -f Makefile.coq
COQDEP VFILES
*** Warning: in file Cava/Arrow/Instances/Netlist.v,
    required library Netlist matches several files in path
    (found Netlist.v in Cava/Arrow/Instances and Cava; used the latter)
COQC Cava/BitArithmetic.v
COQC Cava/Signal.v
COQC Cava/Types.v
COQC Cava/Netlist.v
COQC Cava/Monad/Cava.v
COQC Cava/Monad/Combinators.v
COQC Cava/Monad/UnsignedAdders.v
COQC Cava/Monad/XilinxAdder.v
COQC Cava/Arrow/Arrow.v
COQC Cava/Arrow/Instances/Constructive.v
COQC Cava/Arrow/Instances/Combinational.v
COQC Cava/Arrow/Instances/Netlist.v
File "./Cava/Arrow/Instances/Netlist.v", line 111, characters 2-1820:
Error:
Anomaly
"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."
Please report at http://coq.inria.fr/bugs/.

Coq Version

$ coqtop -v
The Coq Proof Assistant, version 8.11.0 (January 2020)
compiled on Jan 27 2020 17:46:49 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 27 2020 at 09:50):

ejgallego closed Issue #12418 File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed.

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I get the following error message:

"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."

I suspect I have done something wrong :-(

Repo:

$ git clone https://github.com/satnam6502/oak-hardware
$ git checkout 38971a7d0f8aa04b6fa4e21d1dfda3990ecf2c66
$ cd oak-hardware/cava/cava
$ make coq
coq_makefile -f _CoqProject -o Makefile.coq
/Library/Developer/CommandLineTools/usr/bin/make -f Makefile.coq
COQDEP VFILES
*** Warning: in file Cava/Arrow/Instances/Netlist.v,
    required library Netlist matches several files in path
    (found Netlist.v in Cava/Arrow/Instances and Cava; used the latter)
COQC Cava/BitArithmetic.v
COQC Cava/Signal.v
COQC Cava/Types.v
COQC Cava/Netlist.v
COQC Cava/Monad/Cava.v
COQC Cava/Monad/Combinators.v
COQC Cava/Monad/UnsignedAdders.v
COQC Cava/Monad/XilinxAdder.v
COQC Cava/Arrow/Arrow.v
COQC Cava/Arrow/Instances/Constructive.v
COQC Cava/Arrow/Instances/Combinational.v
COQC Cava/Arrow/Instances/Netlist.v
File "./Cava/Arrow/Instances/Netlist.v", line 111, characters 2-1820:
Error:
Anomaly
"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."
Please report at http://coq.inria.fr/bugs/.

Coq Version

$ coqtop -v
The Coq Proof Assistant, version 8.11.0 (January 2020)
compiled on Jan 27 2020 17:46:49 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 27 2020 at 09:56):

Zimmi48 milestoned Issue #12418 File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed.

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I get the following error message:

"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."

I suspect I have done something wrong :-(

Repo:

$ git clone https://github.com/satnam6502/oak-hardware
$ git checkout 38971a7d0f8aa04b6fa4e21d1dfda3990ecf2c66
$ cd oak-hardware/cava/cava
$ make coq
coq_makefile -f _CoqProject -o Makefile.coq
/Library/Developer/CommandLineTools/usr/bin/make -f Makefile.coq
COQDEP VFILES
*** Warning: in file Cava/Arrow/Instances/Netlist.v,
    required library Netlist matches several files in path
    (found Netlist.v in Cava/Arrow/Instances and Cava; used the latter)
COQC Cava/BitArithmetic.v
COQC Cava/Signal.v
COQC Cava/Types.v
COQC Cava/Netlist.v
COQC Cava/Monad/Cava.v
COQC Cava/Monad/Combinators.v
COQC Cava/Monad/UnsignedAdders.v
COQC Cava/Monad/XilinxAdder.v
COQC Cava/Arrow/Arrow.v
COQC Cava/Arrow/Instances/Constructive.v
COQC Cava/Arrow/Instances/Combinational.v
COQC Cava/Arrow/Instances/Netlist.v
File "./Cava/Arrow/Instances/Netlist.v", line 111, characters 2-1820:
Error:
Anomaly
"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."
Please report at http://coq.inria.fr/bugs/.

Coq Version

$ coqtop -v
The Coq Proof Assistant, version 8.11.0 (January 2020)
compiled on Jan 27 2020 17:46:49 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 27 2020 at 10:34):

maximedenes edited PR #12337 Move CoqIDE to its own folder (assigned to gares) from mv-coqide to master:

This will make it possible to put a VsCoq toplevel in ide/vscoq.

It's funny to compare what I had to do to adapt the Makefile build (see the patch below), compared to just moving the folder for Dune.

view this post on Zulip Coq Github Bot (May 27 2020 at 11:00):

maximedenes requested windows-build-maintainers for a review on PR #12337 Move CoqIDE to its own folder.

view this post on Zulip Coq Github Bot (May 27 2020 at 11:00):

maximedenes updated PR #12337 Move CoqIDE to its own folder (assigned to gares) from mv-coqide to master:

This will make it possible to put a VsCoq toplevel in ide/vscoq.

It's funny to compare what I had to do to adapt the Makefile build (see the patch below), compared to just moving the folder for Dune.

view this post on Zulip Coq Github Bot (May 27 2020 at 12:18):

proux01 updated PR #12218 Numeral notations for non inductive types from numeral-notations-non-inductive to master:

This is a tentative implementation of the idea discussed in #12035

This is still lacking some proofs and proper documentation.

Numeral Notation non_inductive via inductive using ...

The main idea is to use actual inductive types that map what you want to parse/print and just translate to (resp. from) the actual type from (resp. to) this inductive type after calling the parser (resp before the printer). One then just has to provide a mapping from globrefs of the actual type to constructors of the inductive type.

For instance, for reals, that looks something like

Inductive IZ :=
| IZpow_pos : Z -> positive -> IZ
| IZ0 : IZ
| IZpos : positive -> IZ
| IZneg : positive -> IZ.

Inductive IR :=
| IRZ : IZ -> IR
| IRQ : Q -> IR
| IRmult : IR -> IR -> IR
| IRdiv : IR -> IR -> IR.

[..]  (* define parser numeral_to_IR and printer IR_to_numeral *)

Numeral Notation R via IR
  using (IZR IRZ, Q2R IRQ, Rmult IRmult, Rdiv IRdiv,
         Z.pow_pos IZpow_pos, Z0 IZ0, Zpos IZpos, Zneg IZneg)
  numeral_to_IR IR_to_numeral : R_scope.

Two notations are provided as examples for Q and R.

Q

Previously rationals were all parsed as a pair numerator, denominator. This means 1.02 and 102e-2 were both parsed as 102 # 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is still parsed as a power of ten denominator but exponents are parsed as a product or division by Z.pow_pos. For instance, 1.02 is parsed as 102 # 100 whereas 102e-2 is parsed as (102 # 1) / (Z.pow_pos 10 2 # 1).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = (102 # 100) * (10 # 1) = 1020 # 100 and 10.2 = 102 # 10 no longer are.

A nice side effect is that exponents can no longer blow up during parsing. Previously 1e1_000_000 literally produced a numerator with a million digits, now it just yields (1 # 1) * (Z.pow_pos 10 1_000_000 # 1).

R

Previously real constants were parsed by an unproved OCaml code. The parser and printer are now implemented in Coq, which will enable a proof and hopefully make it easier to maintain / make evolve.

Previously reals were all parsed as an integer, an integer multiplied by a power of ten or an integer divided by a power of ten. This means 1.02 and 102e-2 were both parsed as 102 / 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is parsed as a rational and exponents are parsed as a product or division by a power of ten. For instance, 1.02 is parsed as Q2R (102 # 100) whereas 102e-2 is parsed as IZR 102 / IZR (Z.pow_pos 10 2).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = Q2R (102 # 100) * 10 and 10.2 = Q2R (102 # 10) no longer are.

TODO

~Depends from: #11948~

view this post on Zulip Coq Github Bot (May 27 2020 at 12:22):

proux01 edited PR #12218 Numeral notations for non inductive types from numeral-notations-non-inductive to master:

This is a tentative implementation of the idea discussed in #12035

This is still lacking some proofs and proper documentation.

Numeral Notation non_inductive via inductive using ...

The main idea is to use actual inductive types that map what you want to parse/print and just translate to (resp. from) the actual type from (resp. to) this inductive type after calling the parser (resp before the printer). One then just has to provide a mapping from globrefs of the actual type to constructors of the inductive type.

For instance, for reals, that looks something like

Inductive IZ :=
| IZpow_pos : Z -> positive -> IZ
| IZ0 : IZ
| IZpos : positive -> IZ
| IZneg : positive -> IZ.

Inductive IR :=
| IRZ : IZ -> IR
| IRQ : Q -> IR
| IRmult : IR -> IR -> IR
| IRdiv : IR -> IR -> IR.

[..]  (* define parser numeral_to_IR and printer IR_to_numeral *)

Numeral Notation R via IR
  using (IZR IRZ, Q2R IRQ, Rmult IRmult, Rdiv IRdiv,
         Z.pow_pos IZpow_pos, Z0 IZ0, Zpos IZpos, Zneg IZneg)
  numeral_to_IR IR_to_numeral : R_scope.

Two notations are provided as examples for Q and R.

Q

Previously rationals were all parsed as a pair numerator, denominator. This means 1.02 and 102e-2 were both parsed as 102 # 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is still parsed as a power of ten denominator but exponents are parsed as a product or division by Z.pow_pos. For instance, 1.02 is parsed as 102 # 100 whereas 102e-2 is parsed as (102 # 1) / (Z.pow_pos 10 2 # 1).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = (102 # 100) * (10 # 1) = 1020 # 100 and 10.2 = 102 # 10 no longer are.

A nice side effect is that exponents can no longer blow up during parsing. Previously 1e1_000_000 literally produced a numerator with a million digits, now it just yields (1 # 1) * (Z.pow_pos 10 1_000_000 # 1).

R

Previously real constants were parsed by an unproved OCaml code. The parser and printer are now implemented in Coq, which will enable a proof and hopefully make it easier to maintain / make evolve.

Previously reals were all parsed as an integer, an integer multiplied by a power of ten or an integer divided by a power of ten. This means 1.02 and 102e-2 were both parsed as 102 / 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is parsed as a rational and exponents are parsed as a product or division by a power of ten. For instance, 1.02 is parsed as Q2R (102 # 100) whereas 102e-2 is parsed as IZR 102 / IZR (Z.pow_pos 10 2).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = Q2R (102 # 100) * 10 and 10.2 = Q2R (102 # 10) no longer are.

TODO

~Depends from: #11948~

view this post on Zulip Coq Github Bot (May 27 2020 at 12:22):

proux01 edited PR #12218 Numeral notations for non inductive types from numeral-notations-non-inductive to master:

This is a tentative implementation of the idea discussed in #12035

This is still lacking some proofs and proper documentation.

Numeral Notation non_inductive via inductive using ...

The main idea is to use actual inductive types that map what you want to parse/print and just translate to (resp. from) the actual type from (resp. to) this inductive type after calling the parser (resp before the printer). One then just has to provide a mapping from globrefs of the actual type to constructors of the inductive type.

For instance, for reals, that looks something like

Inductive IZ :=
| IZpow_pos : Z -> positive -> IZ
| IZ0 : IZ
| IZpos : positive -> IZ
| IZneg : positive -> IZ.

Inductive IR :=
| IRZ : IZ -> IR
| IRQ : Q -> IR
| IRmult : IR -> IR -> IR
| IRdiv : IR -> IR -> IR.

[..]  (* define parser numeral_to_IR and printer IR_to_numeral *)

Numeral Notation R via IR
  using (IZR IRZ, Q2R IRQ, Rmult IRmult, Rdiv IRdiv,
         Z.pow_pos IZpow_pos, Z0 IZ0, Zpos IZpos, Zneg IZneg)
  numeral_to_IR IR_to_numeral : R_scope.

Two notations are provided as examples for Q and R.

Q

Previously rationals were all parsed as a pair numerator, denominator. This means 1.02 and 102e-2 were both parsed as 102 # 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is still parsed as a power of ten denominator but exponents are parsed as a product or division by Z.pow_pos. For instance, 1.02 is parsed as 102 # 100 whereas 102e-2 is parsed as (102 # 1) / (Z.pow_pos 10 2 # 1).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = (102 # 100) * (10 # 1) = 1020 # 100 and 10.2 = 102 # 10 no longer are.

A nice side effect is that exponents can no longer blow up during parsing. Previously 1e1_000_000 literally produced a numerator with a million digits, now it just yields (1 # 1) * (Z.pow_pos 10 1_000_000 # 1).

R

Previously real constants were parsed by an unproved OCaml code. The parser and printer are now implemented in Coq, which will enable a proof and hopefully make it easier to maintain / make evolve.

Previously reals were all parsed as an integer, an integer multiplied by a power of ten or an integer divided by a power of ten. This means 1.02 and 102e-2 were both parsed as 102 / 100 and could not be tell apart when printing. So the printer had to choose between two representations : without exponent or without decimal dot. The choice was made heuristically toward a most compact representation.

Now, decimal dot is parsed as a rational and exponents are parsed as a product or division by a power of ten. For instance, 1.02 is parsed as Q2R (102 # 100) whereas 102e-2 is parsed as IZR 102 / IZR (Z.pow_pos 10 2).

1.02 and 102e-2 remain equal (proved by reflexivity) but 1.02e1 = Q2R (102 # 100) * 10 and 10.2 = Q2R (102 # 10) no longer are.

TODO

~Depends from: #11948~

view this post on Zulip Coq Github Bot (May 27 2020 at 13:13):

Mbodin updated PR #12389 Small coq_makefile improvement. (assigned to gares) from coq_makefile to master:

Kind: feature.

Relates to #7740 and #7722.

The behaviour of coq_makefile regarding DESTDIR is somehow confusing (as seen in the related bug reports above). The “usual” set-up in Linux seems to be:

The COQMF_WINDRIVE parts feels like a hack and is currently undocumented. This PR provides an alternative way (without breaking the previous way):

Being able to set up the installation directory is especially important when using programs like esy, in which different Coq installation can be shared among repositories: esy installs Coq libraries into their own directory, relying on the COQPATH mechanism to link everything back together. By forcing the installation to ${COQLIB}/user-contrib, coq_makefile is installing files in a shared folder, which breaks esy’s invariants required for replication.

view this post on Zulip Coq Github Bot (May 27 2020 at 13:42):

Zimmi48 submitted PR Review for #12396 Release notes 8.12.

view this post on Zulip Coq Github Bot (May 27 2020 at 13:42):

Zimmi48 created PR Review Comment on #12396 Release notes 8.12:

Sorry, I missed most of your comments last time:

Will we mention the doc improvements (and the plans for subsequent improvements) more prominently, such as in the email announcing the release?

There's a summary to be written above, which highlights a selection of changes. The documentation changes in 8.12 are clearly one of the highlights to be done.

The e-mail announcing the release will repeat these highlights. But in addition, the 8.12+beta1 announcement should include a call for beta readers of the manual and for help in improving the presentation further. I'll get back to you for help writing this call.

view this post on Zulip Coq Github Bot (May 27 2020 at 13:51):

ejgallego unlabeled Issue #12418 File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed.

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I get the following error message:

"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."

I suspect I have done something wrong :-(

Repo:

$ git clone https://github.com/satnam6502/oak-hardware
$ git checkout 38971a7d0f8aa04b6fa4e21d1dfda3990ecf2c66
$ cd oak-hardware/cava/cava
$ make coq
coq_makefile -f _CoqProject -o Makefile.coq
/Library/Developer/CommandLineTools/usr/bin/make -f Makefile.coq
COQDEP VFILES
*** Warning: in file Cava/Arrow/Instances/Netlist.v,
    required library Netlist matches several files in path
    (found Netlist.v in Cava/Arrow/Instances and Cava; used the latter)
COQC Cava/BitArithmetic.v
COQC Cava/Signal.v
COQC Cava/Types.v
COQC Cava/Netlist.v
COQC Cava/Monad/Cava.v
COQC Cava/Monad/Combinators.v
COQC Cava/Monad/UnsignedAdders.v
COQC Cava/Monad/XilinxAdder.v
COQC Cava/Arrow/Arrow.v
COQC Cava/Arrow/Instances/Constructive.v
COQC Cava/Arrow/Instances/Combinational.v
COQC Cava/Arrow/Instances/Netlist.v
File "./Cava/Arrow/Instances/Netlist.v", line 111, characters 2-1820:
Error:
Anomaly
"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."
Please report at http://coq.inria.fr/bugs/.

Coq Version

$ coqtop -v
The Coq Proof Assistant, version 8.11.0 (January 2020)
compiled on Jan 27 2020 17:46:49 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 27 2020 at 13:52):

ejgallego labeled Issue #12418 File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed.

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I get the following error message:

"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."

I suspect I have done something wrong :-(

Repo:

$ git clone https://github.com/satnam6502/oak-hardware
$ git checkout 38971a7d0f8aa04b6fa4e21d1dfda3990ecf2c66
$ cd oak-hardware/cava/cava
$ make coq
coq_makefile -f _CoqProject -o Makefile.coq
/Library/Developer/CommandLineTools/usr/bin/make -f Makefile.coq
COQDEP VFILES
*** Warning: in file Cava/Arrow/Instances/Netlist.v,
    required library Netlist matches several files in path
    (found Netlist.v in Cava/Arrow/Instances and Cava; used the latter)
COQC Cava/BitArithmetic.v
COQC Cava/Signal.v
COQC Cava/Types.v
COQC Cava/Netlist.v
COQC Cava/Monad/Cava.v
COQC Cava/Monad/Combinators.v
COQC Cava/Monad/UnsignedAdders.v
COQC Cava/Monad/XilinxAdder.v
COQC Cava/Arrow/Arrow.v
COQC Cava/Arrow/Instances/Constructive.v
COQC Cava/Arrow/Instances/Combinational.v
COQC Cava/Arrow/Instances/Netlist.v
File "./Cava/Arrow/Instances/Netlist.v", line 111, characters 2-1820:
Error:
Anomaly
"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."
Please report at http://coq.inria.fr/bugs/.

Coq Version

$ coqtop -v
The Coq Proof Assistant, version 8.11.0 (January 2020)
compiled on Jan 27 2020 17:46:49 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 27 2020 at 13:53):

ejgallego reopened Issue #12418 File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed.

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I get the following error message:

"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."

I suspect I have done something wrong :-(

Repo:

$ git clone https://github.com/satnam6502/oak-hardware
$ git checkout 38971a7d0f8aa04b6fa4e21d1dfda3990ecf2c66
$ cd oak-hardware/cava/cava
$ make coq
coq_makefile -f _CoqProject -o Makefile.coq
/Library/Developer/CommandLineTools/usr/bin/make -f Makefile.coq
COQDEP VFILES
*** Warning: in file Cava/Arrow/Instances/Netlist.v,
    required library Netlist matches several files in path
    (found Netlist.v in Cava/Arrow/Instances and Cava; used the latter)
COQC Cava/BitArithmetic.v
COQC Cava/Signal.v
COQC Cava/Types.v
COQC Cava/Netlist.v
COQC Cava/Monad/Cava.v
COQC Cava/Monad/Combinators.v
COQC Cava/Monad/UnsignedAdders.v
COQC Cava/Monad/XilinxAdder.v
COQC Cava/Arrow/Arrow.v
COQC Cava/Arrow/Instances/Constructive.v
COQC Cava/Arrow/Instances/Combinational.v
COQC Cava/Arrow/Instances/Netlist.v
File "./Cava/Arrow/Instances/Netlist.v", line 111, characters 2-1820:
Error:
Anomaly
"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."
Please report at http://coq.inria.fr/bugs/.

Coq Version

$ coqtop -v
The Coq Proof Assistant, version 8.11.0 (January 2020)
compiled on Jan 27 2020 17:46:49 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 27 2020 at 13:53):

ejgallego demilestoned Issue #12418 File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed.

<!-- Thank you for reporting a bug to Coq! -->

Description of the problem

I get the following error message:

"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."

I suspect I have done something wrong :-(

Repo:

$ git clone https://github.com/satnam6502/oak-hardware
$ git checkout 38971a7d0f8aa04b6fa4e21d1dfda3990ecf2c66
$ cd oak-hardware/cava/cava
$ make coq
coq_makefile -f _CoqProject -o Makefile.coq
/Library/Developer/CommandLineTools/usr/bin/make -f Makefile.coq
COQDEP VFILES
*** Warning: in file Cava/Arrow/Instances/Netlist.v,
    required library Netlist matches several files in path
    (found Netlist.v in Cava/Arrow/Instances and Cava; used the latter)
COQC Cava/BitArithmetic.v
COQC Cava/Signal.v
COQC Cava/Types.v
COQC Cava/Netlist.v
COQC Cava/Monad/Cava.v
COQC Cava/Monad/Combinators.v
COQC Cava/Monad/UnsignedAdders.v
COQC Cava/Monad/XilinxAdder.v
COQC Cava/Arrow/Arrow.v
COQC Cava/Arrow/Instances/Constructive.v
COQC Cava/Arrow/Instances/Combinational.v
COQC Cava/Arrow/Instances/Netlist.v
File "./Cava/Arrow/Instances/Netlist.v", line 111, characters 2-1820:
Error:
Anomaly
"File "pretyping/cases.ml", line 1719, characters 29-35: Assertion failed."
Please report at http://coq.inria.fr/bugs/.

Coq Version

$ coqtop -v
The Coq Proof Assistant, version 8.11.0 (January 2020)
compiled on Jan 27 2020 17:46:49 with OCaml 4.09.0

view this post on Zulip Coq Github Bot (May 27 2020 at 13:56):

ejgallego edited Issue #12417 Encountered an Anomaly when defining a Function:

Description of the problem

Hi, I am trying to define a function with a non-standard recursion pattern and encountered an
anomaly on the sum_total function: ' Anomaly "Uncaught exception Retyping.RetypeError(0)." '

Require Import List.
Require Export PeanoNat.
Require Export Omega.
Require Export CpdtTactics.
Require Import FunInd.
Require Import Recdef.

Notation "A :: B" := (cons A B).
Notation "[]" := nil.
Notation "[[ A ]]" := (A :: nil).

Inductive tm :=
| E: nat -> tm
| L: list tm -> tm.

Definition T := list tm.

Fixpoint max_list (p: nat) (l: list nat) : nat :=
  match l with
  | [] => p
  | n :: l' => max_list (Init.Nat.max n p) l'
  end.

Fixpoint depth (t: tm) : nat :=
  match t with
  | E _ => 0
  | L l => 1 + max_list 0 (map depth l)
  end.

Fixpoint sum_depth (l: T) : nat :=
  match l with
  | [] => 0
  | n :: l' => (depth n) + sum_depth l'
  end.

Definition sum_depth_order (t1 t2 : T) :=
  sum_depth t1 < sum_depth t2.

Hint Constructors Acc.

Lemma sum_depth_order_wf' : forall d l, sum_depth l <= d ->
  Acc sum_depth_order l.
Proof.
  unfold sum_depth_order. induction d; intros.

  - assert (sum_depth l = 0). omega.
    apply Acc_intro.</