I hope the official team can automatically upgrade the Docker container

The Docker image I use is casbin/casdoor: v1.32.0. When I try to change the image to casbin/casdoor: v1.157.0, an error occurs:

[xorm] [warn]  2022/11/14 02:20:21.194025 Table cert has column public_key but struct has not related field
[xorm] [warn]  2022/11/14 02:20:21.220707 Table casbin_rule has column p_type but struct has not related field
[xorm] [warn]  2022/11/14 02:20:21.233234 Table casbin_rule has column p_type but struct has not related field
panic: runtime error: slice bounds out of range [:1] with length 0
goroutine 1 [running]:
github.com/casbin/casbin/v2/persist.LoadPolicyLine({0xc0001855a0, 0x19}, 0x7)
        /go/pkg/mod/github.com/casbin/casbin/v2@v2.30.1/persist/adapter.go:41 +0x4a5
github.com/casbin/xorm-adapter/v3.loadPolicyLine(0xc000695110, 0x15c7680)
        /go/pkg/mod/github.com/casbin/xorm-adapter/v3@v3.0.1/adapter.go:269 +0x245
github.com/casbin/xorm-adapter/v3.(*Adapter).LoadPolicy(0xc00009ba40, 0x17b3940)
        /go/pkg/mod/github.com/casbin/xorm-adapter/v3@v3.0.1/adapter.go:281 +0x15f
github.com/casbin/casbin/v2.(*Enforcer).LoadPolicy(0xc00069a800)
        /go/pkg/mod/github.com/casbin/casbin/v2@v2.30.1/enforcer.go:275 +0x42
github.com/casbin/casbin/v2.(*Enforcer).InitWithModelAndAdapter(0xc00069a800, 0x18df6a0, {0x7f5b02f359e8, 0xc00009ba40})
        /go/pkg/mod/github.com/casbin/casbin/v2@v2.30.1/enforcer.go:169 +0xfe
github.com/casbin/casbin/v2.NewEnforcer({0xc0005cfeb0, 0x2, 0x1})
        /go/pkg/mod/github.com/casbin/casbin/v2@v2.30.1/enforcer.go:105 +0x406
github.com/casdoor/casdoor/authz.InitAuthz()
        /go/src/casdoor/authz/authz.go:68 +0x18e
main.main()
        /go/src/casdoor/main.go:44 +0x158

It seems that the incompatibility is caused by the change of database structure. I hope the upgrade script can be integrated into the new version of Docker image. When it is judged that the data is old, it will be automatically upgraded

@forestmgy

Do you have a table named migrations in your database?

@star7th Or you can drop permission_rule and casbin_rule and restart. I 'll find why it is not work in Docker

There is no table called migrations.
I drop permission_ rule and casbin_rule and restart . It works.

But there are two other problems. I don't know whether to write them here or issue them again

After v1.32.0 is upgraded to v1.157.0, the super administrator account admin cannot log in with the original password. I don't know if this is related to the encryption method I changed in the background.
When I reset the password by email, it prompts "tls: first record does not look like a TLS handshake" before sending the email verification code

But there are two other problems. I don't know whether to write them here or new issue

After v1.32.0 is upgraded to v1.157.0, the super administrator account admin cannot log in with the original password. I don't know if this is related to the encryption method I changed in the background.
When I reset the password by email, it prompts "tls: first record does not look like a TLS handshake" before sending the email verification code

@star7th maybe you can open a new issue

Moved to: https://github.com/casdoor/casdoor/issues/1295


ConvAsm3x3U big tensor support

This PR expands the range of valid values for i/o tensors of ConvAsm3x3U solver. Also resolves issue #609 ~issue~ and removes temporary limits introduced in #643 PR.

Have you tested how this PR affects performance?

@Slimakanzer Are you pretty sure that 15 test cases is enough for correctness testing? Or actual amount of testing is somewhat bigger?

@atamazov Updated list of verified cases. The list contains only big-tensors. A lot of small tensors have also been tested. Cases were verified only on gfx9 and verification was not performed at gfx8, however, only instructions were used that are in gfx9 isa and gfx8 isa.

@atamazov Updated list of verified cases. The list contains only big-tensors. A lot of small tensors have also been tested. Cases were verified only on gfx9 and verification was not performed at gfx8, however, only instructions were used that are in gfx9 isa and gfx8 isa.


Add img_data() helper

Description
Adds an image helper function to create a data tag from a file path.
Checklist:

[X] Securely signed commits
[X] Component(s) with PHPdocs
[X] Unit testing, with >80% coverage
[X] User guide updated
[X] Conforms to style guide

All green!

C'mon @paulbalandan - you know you want to merge it.

Alright then. 😂


Values written in  context in first step is not available in the next

What happened?

Step 1 of my function is writting to the pipeline context like so
  _ctx = option("params").ctx
  _ctx.namespace = "mynamespace"

I can display the value of option("params").ctx inside the step1 but not in a step further down with the following code
 _ctx = option("params").ctx
 items = [{ctx = _ctx}]

the context is then empty.
What environment did it happen in?
Function version: 0.10.10

Sorry @Peefy for not including this before.
Here is the steps as defined in my composition
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: generic-app-definition
spec:
  compositeTypeRef:
    apiVersion: apps.xxxx.tech/v1alpha1
    kind: XRApp
  mode: Pipeline
  pipeline:
  - step: step1
    functionRef:
      name: kcl-function
    input:
      apiVersion: krm.kcl.dev/v1alpha1
      kind: KCLInput
      spec:
        dependencies: |
          k8s="1.31"
          crossplane-provider-kubernetes="0.9.2"
        source: |
          _ctx = option("params").ctx
          _ctx.namespace = "mynamespace"
          object = {
             apiVersion: "nopexample.org/v1"
             metadata.name = "object from step1"
             metadata.namespace = _ctx.namespace
             spec = {
             }
          }
          items = [object]

   - step: step2
    functionRef:
      name: kcl-function
    input:
      apiVersion: krm.kcl.dev/v1alpha1
      kind: KCLInput
      spec:
        dependencies: |
          k8s="1.31"
          crossplane-provider-kubernetes="0.9.2"
        source: |
          _ctx = option("params").ctx
          object = {
             apiVersion: "nopexample.org/v1"
             metadata.name = "object from step2"
             metadata.namespace = _ctx.namespace
             spec = {
             }
          }

          items = [object]

The output from crossplane render
---
apiVersion: apps.chainstar.tech/v1alpha1
kind: App
metadata:
  name: myapp
status:
  conditions:
  - lastTransitionTime: "2024-01-01T00:00:00Z"
    message: 'Unready resources: object from step1, object from step2'
    reason: Creating
    status: "False"
    type: Ready
---
apiVersion: nopexample.org/v1
metadata:
  annotations:
    crossplane.io/composition-resource-name: object from step1
  generateName: myapp-
  labels:
    crossplane.io/composite: myapp
  name: object from step1
  namespace: mynamespace
  ownerReferences:
  - apiVersion: apps.chainstar.tech/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: App
    name: myapp
    uid: ""
spec: {}
---
apiVersion: nopexample.org/v1
metadata:
  annotations:
    crossplane.io/composition-resource-name: object from step2
  generateName: myapp-
  labels:
    crossplane.io/composite: myapp
  name: object from step2
  ownerReferences:
  - apiVersion: apps.chainstar.tech/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: App
    name: myapp
    uid: ""
spec: {}

:point_up:  I would expect a the "mynamespace" value in the metadata.namespace property from "Object from step2"

Sorry @Peefy I don't get it. I am trying to use the content of the ctx from one Step to another one.
Do I need to return it into items to be able to use it in another step? (I actually tried that but it does not work) .
I am feeling I am not seeing the elephant in the room here. Apologies if that's the case ..

Hi @spastorclovr, I think writing to context is still not supported in KCL, see #134
You can read it in KCL but you can't return anything back for now.


move onto a parser-based link detection system

I'll hazard a guess that VSCode Python traceback links usually don't work, since most people have spaces in their home directory
          This is by design until we move onto a parser-based link detection system.

... this was commetned by @Tyriar in September 2019. Is that still planned?
Here's a zoo of closed issues referencing this problem, that has existed basically since the inception of vscode.
https://github.com/microsoft/vscode-python/issues/7491
https://github.com/microsoft/vscode/issues/81190
https://github.com/microsoft/vscode/issues/21125
https://github.com/microsoft/vscode/issues/97941
It's ok; if the feature doesn't work, just admit that, and remove it entirely. It's more annoying having these weird half-link things hanging around in the terminal, eating up CPU cycles and creating little mines that you might accidentally hit with your cursor when trying to select text or scroll.
Don't release software that doesn't work and pretend it does. That's Google's thing, Microsoft can't copy it

@tsbertalan can you share some links that don't work? We've made some pretty significant changes in recent releases to both how links work behind the scenes and the number of formats we can detect https://code.visualstudio.com/updates/v1_75#_link-improvements (and many that weren't mentioned in release notes), that includes Python traces:

Python-style stack trace links: File "<path>", line <line>

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Change format for OrderID and OrderItemID

Previously these were UUID format now they are just strings
This was reported by QE when they were testing this from the Swagger UI
The Swagger Editor fixes the basePath it doesn't need quotes like @Fryguy had it in PR #11

The format allows for extra validations I have seen password and uuid there could be others


how to port feedstock to new compilers

@conda-forge/core
Is the bot still creating migration PR's for new-compilers? If not is there still a way to do it manually?

done


Make notebook saving more robust by catching exceptions

Description
Colab internals have changed and there were calls that were not robust to these changes.

Quick fix is to catch this exception.  Longer term fix is to be more strict about assumptions made about external interfaces.
Log will have:
2022-08-22 16:24:05,105 INFO    MainThread:56 [jupyter.py:save_ipynb():384] Problem saving notebook: KeyError('name')

Testing
Manual:
pip install --upgrade git+https://github.com/wandb/wandb.git@fix-colab#egg=wandb

Would be nice to actually fix colab saving. Do we know where the notebook name moved?

Done, based on your suggestion.


UI sublattices feature

[ ] I have added the tests to cover my changes.
[x] I have updated the documentation and CHANGELOG accordingly.
[x] I have read the CONTRIBUTING document.

This PR will contain the ability to view the sublattices as part of the main lattice graph.

@AlejandroEsquivel  Few fixes were made and now the PR is ready to be reviewed. Thanks.

Sounds good @Prasy12 I will take a look


various cleanups

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (07f6486) 95.06% compared to head (91c52f5) 95.06%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #202   +/-   ##
=======================================
  Coverage   95.06%   95.06%
=======================================
  Files          21       21
  Lines         162      162
  Branches       14       14
=======================================
  Hits          154      154
  Misses          8        8

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fix panic when metadata is nil

Feel free to close if there's a better solution :)
fixes #1435

/approve

/ok-to-test

Nice @matt-simons, thank you :)
Would you mind adding a unit test for this? It might involve a duplicate/edit of fakeInstallConfigYaml here...

Added a test case for when neither metadata nor basedomain are provided in the install-config.

Very nice, thanks @matt-simons.
/lgtm


We need a separate docs repository

Similar to OceananigansDocumentation. Our repo is getting large I think because of the docs movies and stuff:
greg@tartarus:~/Projects$ git clone https://github.com/CliMA/OceanLearning.jl.git
Cloning into 'OceanLearning.jl'...
remote: Enumerating objects: 6757, done.
remote: Counting objects: 100% (206/206), done.
remote: Compressing objects: 100% (114/114), done.
remote: Total 6757 (delta 82), reused 173 (delta 65), pack-reused 6551
Receiving objects: 100% (6757/6757), 106.53 MiB | 18.67 MiB/s, done.
Resolving deltas: 100% (4484/4484), done.

Gotcha!

Let's settle on a name first; see #230


False Positive - JWT detected in issue quote reply

Pattern Name / Description
We are getting false positived while using the JWT custom pattern e(?:y[IJ]|yL[CD]|yA[JKgi]|w[ko][JKgi])[A-Za-z0-9_-]{10,}(?:fQ|[3HXn]0|[1BFJNRVZdhlpx]9)={0,2}\.e(?:y[IJ]|yL[CD]|yA[JKgi]|w[ko][JKgi])[A-Za-z0-9_-]{10,}(?:fQ|[3HXn]0|[1BFJNRVZdhlpx]9)={0,2}(?:\.?[A-Za-z0-9_-]+={0,2})? (from https://github.com/advanced-security/secret-scanning-custom-patterns/tree/main/jwt#readme) in some of our GitHub issues.
The pattern is matched in "quote reply" of comments containing an image.
Sample Snippet

This is something I have already quickly mentioned to @aegilops.
Happy to provide further details if needed.

Thanks @vthiery, @aegilops and I will take a look next week for you

Ah, this is an interesting one. We do correctly detect a JWT, but the context in which it is detected it is benign. It's a GitHub generated JWT to access a private image, and not part of the user-generated content.
I'll see if there's something in the structure of this to help remove it from consideration.
Thanks so much for the report!

Can you try adding this in the custom pattern UI as an additional match that must not match please?
^eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9\.eyJrZXkiOiJrZXkxIiwiZXhwIjo[A-Za-z0-9_-]+(JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9|ZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ|mWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0)\.

As in, here:

If you confirm that works for you then I'll put that into the repo.
What that does is match parts of the JWT that are somewhat indicative of this kind of JWT. It'll possibly result in some false negatives, since it isn't very distinctive.
Because of the way that custom patterns work it's not possible for me to make use of the URL content before the JWT in deciding to ignore it - that would be my first choice, to say "ignore if in a URL for private-user-images.githubusercontent.com/".

Thanks @aegilops for the quick answer. I just tested your suggestion and it works well for quote replies in issues.
Nevertheless, I got another unwanted match in a quote reply in a pull-request, for which the JWT was missing the signature.
I adjusted the pattern to remove the ending . and it now works as expected, i.e. not matching any of the JWT in issue/pr comments.

I'll raise something internally to see if we can make these JWT for this purpose more easily identifiable

We made a change to the JWT format.
The payload of the JWT will always be prefixed with {"iss":"github.com","aud":"raw.githubusercontent.com",, which has fixed Base64 of eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIs.
You will need to adjust your custom pattern in light of that change, since the previous pattern won't work now.
I'll make a change to the custom pattern YAML file to reflect that.

Thanks @aegilops ! I reconfigured the rule and so far so good :+1:


void-symbol: native-comp-deferred-compilation-deny-list errors on install/upgrade

What did you expect to happen?

Install to be successful.

Using Ubuntu 20.04.
add-apt-repository ppa:kelleyk/emacs

What actually happened?
tim@wrath:~$ ls -ld .emacs.d .doom.d
ls: cannot access '.emacs.d': No such file or directory
ls: cannot access '.doom.d': No such file or directory
tim@wrath:~$ emacs --version
GNU Emacs 27.1
Copyright (C) 2020 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
tim@wrath:~$ apt-cache show emacs27
Package: emacs27
Priority: optional
Section: editors
Installed-Size: 21294
Maintainer: Kevin Kelley<EMAIL_ADDRESS>Architecture: amd64
Version: 27.1~1.git86d8d76aa3-kk2+20.04
Replaces: emacs27-nox
...
tim@wrath:~$ git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
Cloning into '/home/tim/.emacs.d'...
...
tim@wrath:~$ ~/.emacs.d/bin/doom install
> Installing straight...
  > Cloning use-package...
> Executing 'doom install' with Emacs 27.1 at 2021-10-24 13:05:47
  Installing Doom Emacs!

  > Creating .doom.d/
    ✓ Created .doom.d/
  - Creating .doom.d/init.el
  ✓ Done!
  - Creating .doom.d/config.el
  ✓ Done!
  - Creating .doom.d/packages.el
  ✓ Done!
Generate an envvar file? (see `doom help env` for details) (y or n) n
  Installing plugins
  > Installing packages...
    > Building straight...
    - Checked out use-package: a7422fb8ab1baee19adb2717b5b47b9c3812a84c
    > Building use-package...
    > Building use-package > Building bind-key...
    > Building use-package...
    > Updating recipe repos...
    > Cloning auto-minor-mode...csmirror-mirror...
    - Checked out auto-minor-mode: 17cfa1b54800fdef2975c0c0531dad34846a5065
    > Building auto-minor-mode...
...
    > Cloning drag-stuff.el...
    > Building drag-stuff...
    > Cloning link-hint.el...
    > Building link-hint...
    x There was an unexpected error
      Message: Symbol's value as variable is void
      Error: (void-variable native-comp-deferred-compilation-deny-list)
      Backtrace:
        (add-to-list native-comp-deferred-compilation-deny-list "\\`/home/tim/\\.e...
        (apply add-to-list (native-comp-deferred-compilation-deny-list "\\`/home/t...
        (#[128 "\302\300\303\301\"\"\207" [add-to-list (native-comp-deferred-comp...
        (mapc #[128 "\302\300\303\301\"\"\207" [add-to-list (native-comp-deferred...
        ((closure (t) nil (mapc (doom-partial #'add-to-list 'native-comp-deferred-...
        (#[0 "	\204\300 \207	\302\303!\211\304\305\306\307\310\3#\311\"\31...
        (compat--require #<subr require> comp nil t)
        (apply compat--require #<subr require> (comp nil t))
        (require comp nil t)
        (and (require 'comp nil t) (condition-case nil (progn (native-comp-availab...
    ! Extended backtrace logged to .emacs.d/.local/doom.error.log

Describe your attempts to resolve the issue

Blew away .emacs.d and .doom.d and tried again. Same result.

Steps to reproduce

Follow install instructions for Ubuntu.

System Information
https://pastebin.com/BN1QHgdj

Same error on macOS 11.6 with emacs-mac 27.2 doing a doom upgrade (and now doom sync)
Workaround, worked around it.

I'll tentatively close this, as it seems to have resolved itself.


Make alias optional for apksigner

Keep in mind, jarsigner still requires an alias which is being used here for signing aab files.
This was noted in the README.

Thanks @Yakov5776!


Can you please provide your vscode settings it is very clean

Can you please provide your vscode settings it is very clean so that i can feel the vibes you were getting with these theme plz :)

Hi! You can find most of the settings I was using at the time of the screenshots in my dotfiles. A few things have shifted a bit with the theme itself since then, but I believe most of what you're looking for should be in there!


food main exhibit painting

All of the paintings here are absolutely delicious – except for one – “Brussel Sprouts in Watercolor.” It’s in a corner, not really displayed, and no one cares if you take it, it’s yucky.

why these specific foods

They are already represented in other art pieces

ah

Art by DemiDude, implement


Interactive dependency prompt for bower install

Hello, I am using a simple recipe to deploy on a staging server that requires a bower install.
Everything runs smoothly until bower presents an interactive prompt to ask for a dependency version (in my case angular). If I run it on the server, I can select my choice, but with deployer it exits with
 [RuntimeException]
  bower                                             ECONFLICT Unable to find suitable version for angular

Not sure if this is phpseclib related and if the completion of #348 will fix it or there is something I could do to get the interactive prompt work.
All help and advice is highly appreciated.
Here's my task:
/*
 * Run bower install
 */
task('deploy:bower_install', function () {
  cd('{{release_path}}');
  run('bower install');
})->desc('running bower install');

Deployer version 3.0.10
PHP 5.5.30
Bower 1.7.7
Deployment target: Ubuntu 14.04 LTS

Thanks.

Hi,
Configure bower to not asking you about it :)


Updated JSON property to correct value

When updating a single member using Member ID (so you can update an email address for someone), the API is expecting "email" not "member_email". Successfully tested.

Great catch @MikeSmithDev.


How to get a user who pressed a button?

My bot replies to a message with his answer and a button with some action on it.
There are several users in the chat, and I wonder how I get the user who pressed this button in the action method.

You can retrieve user information from the $callbackQuery property in your Webhook Handler
then I think you can store the telegram user ID in your application user model


Include weapons in optimization

Now that more and more weapons with ever unique conditionals are being added to the game its getting harder to "solve" which weapon is the best for a character depending in your optimization target.
For exmaple my Xiangling with several popular 4* weapon options are all very close just with Vaped Pyronado AVG damage vs ER%.
This does not take into account setting certain minimum constraints or multi-target optimization.

A suggestion would be to add another button under "Use Equipped Artifacts" with a settings cog that allows you to enable all conditionals and include/exclude certain weapons for that character:

Seems to be an influx of requests recently:

HAHAHA I ALMOST POSTED THIS REQUEST XD
I feel a little bad for frzyc getting bombarded with requests for it but it's a very very wanted feature lol.

For now, probably just switch from weapon to weapon then optimize artifact. After each one check which has the best damage!
Kind of like this: (Flawed since the artifacts didn't change when I switched out weapons and clicked optimize again)


add coriolis package

Upstream: https://gitlab.lip6.fr/vlsi-eda/coriolis
Build documentation: https://gitlab.lip6.fr/vlsi-eda/coriolis/-/blob/devel/README.rst#L38
Dependencies:

Python 3
cmake
boost
bison & flex
Qt 4 or 5
libxml2
RapidJSON

Seems like qt is a hard-dep: https://gitlab.lip6.fr/vlsi-eda/coriolis/-/blob/devel/bootstrap/cmake_modules/FindBootstrap.cmake#L211

While I would love to see this, I would say it is a much lower priority than Xyce / OpenLane / etc.

New upstream repos:

https://github.com/lip6/coriolis
https://github.com/lip6/alliance
https://github.com/lip6/alliance-check-toolkit
https://github.com/lip6/tas-yagle


postmessage_structured_test fails on IE9

Test times out.
Reason currently unknown.

Obsolete.  IE9 no longer supported.


JDK10 Compatibility

It will be nice to add jdk10 in build matrix, but travis not yet support jdk10 out of the box https://github.com/travis-ci/travis-ci/issues/9368

Also we can use jdk11 on CI.

Travis config updated in all modules. All modules expect https://github.com/bootique/bootique-tapestry/ works on JDK10. For JDK11 we need to release https://github.com/bootique/bootique-modules-parent/ and migrate all repos to new parent.


Terms of Service

When a user is logged in, but before they go to the dashboard, they must agree to the Terms of Service. Once they have agreed, the database records the time that they agreed, and the user will not be shown this screen again.
This PR focuses on the functionality -- the button layout needs some styling, and the text was simply copied from old Dryad. It will need to be updated.
To test: Login and go to the dashboard (aka "My Datasets")

Hi Ryan,
It looks like this breaks the tests in the dryad repository because it adds an extra page to the login workflow.
I'd look into the file dryad/spec/features_helper.rb around line 148.  It gets run before lots of tests to log the user into the main interface.
I believe if you simply add another line to continue through the acceptance as part of the login flow then many of the failed tests will stop failing.
If you want to "freeze" the web browser open while running the test and debug, just put 'byebug' on the line and then you can see where the breakpoint stops and some things that are going on.
The other thing you may want to do is to add a test from the UI for this specific scenario.  You'll need to also maybe modify the dryad/spec/features/login_spec.rb .
Depending how you look at this feature you could add some other section to that file and test each button to be sure the feature works.  Maybe a section like "describe 'Accepting Terms of Service'" or something.
When I have to change both repositories (Dryad and Stash), to complete a feature, I'll usually create the same branch name on both repositories so that it's clear those changes are paired.
Then I'll note in the PR that the two branches go together and create a PR in each repository.
This kind of hassle is why I believe it would be nice to merge the two repositories into one.  Since in practical terms this is a pain to have to do all the time and also harder to review for other people, too.

This looks good to me, Ryan.  The disagree button is working great now.
I'm going to hold off on the merge a bit just so our dryad repo tests don't break, but I hope those changes won't be too bad.  Let me know when it's done and I'll accept both pull requests.

This looks good, Ryan.  I was going to wait a bit for the tests in the main Dryad repo, but no need to hold up on it so merging now.


delete unused variable

as I see the code is not used. So I can delete and make the time execute faster

How much faster does this make it?

Thank you for your contribution!


Tomplusplus 3.3.0 build failed on android

Environment
toml++ version and/or commit hash:  3.3.0

Compiler:  android-r25c on Linux

C++ standard mode:

Target arch:

Library configuration overrides:

Relevant compilation flags:

Describe the bug

I am a member of vcpkg, when I updating tomplusplus to version 3.3.0, it build failed on arm-android with the following errors:
[1/3] /android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -Isrc/libtomlplusplus.a.p -Isrc -I../src/v3.3.0-055894c820.clean/src -Iinclude -I../src/v3.3.0-055894c820.clean/include -I/mnt/vcpkg-ci/installed/arm-neon-android/include -fvisibility=hidden -fcolor-diagnostics -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O0 -g --target=armv7-none-linux-androideabi21 -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security -frtti -fexceptions -fPIC --sysroot=/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -fno-limit-debug-info -fPIC -ferror-limit=5 -Wno-unused-command-line-argument -Wno-reserved-macro-identifier -fchar8_t -D_HAS_EXCEPTIONS=1 -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-documentation -Wno-documentation-unknown-command -Wno-switch-enum -Wno-covered-switch-default -Wno-padded -Wno-float-equal -DTOML_HEADER_ONLY=0 -MD -MQ src/libtomlplusplus.a.p/toml.cpp.o -MF src/libtomlplusplus.a.p/toml.cpp.o.d -o src/libtomlplusplus.a.p/toml.cpp.o -c ../src/v3.3.0-055894c820.clean/src/toml.cpp
FAILED: src/libtomlplusplus.a.p/toml.cpp.o
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -Isrc/libtomlplusplus.a.p -Isrc -I../src/v3.3.0-055894c820.clean/src -Iinclude -I../src/v3.3.0-055894c820.clean/include -I/mnt/vcpkg-ci/installed/arm-neon-android/include -fvisibility=hidden -fcolor-diagnostics -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O0 -g --target=armv7-none-linux-androideabi21 -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security -frtti -fexceptions -fPIC --sysroot=/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -fno-limit-debug-info -fPIC -ferror-limit=5 -Wno-unused-command-line-argument -Wno-reserved-macro-identifier -fchar8_t -D_HAS_EXCEPTIONS=1 -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-documentation -Wno-documentation-unknown-command -Wno-switch-enum -Wno-covered-switch-default -Wno-padded -Wno-float-equal -DTOML_HEADER_ONLY=0 -MD -MQ src/libtomlplusplus.a.p/toml.cpp.o -MF src/libtomlplusplus.a.p/toml.cpp.o.d -o src/libtomlplusplus.a.p/toml.cpp.o -c ../src/v3.3.0-055894c820.clean/src/toml.cpp
In file included from ../src/v3.3.0-055894c820.clean/src/toml.cpp:13:
In file included from ../src/v3.3.0-055894c820.clean/include/toml++/toml.h:69:
In file included from ../src/v3.3.0-055894c820.clean/include/toml++/impl/parser.inl:26:
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/fstream:952:20: error: use of undeclared identifier 'ftello'; did you mean 'ftell'?
    pos_type __r = ftello(__file_);
                   ^
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/cstdio:141:9: note: 'ftell' declared here
using ::ftell;
        ^
In file included from ../src/v3.3.0-055894c820.clean/src/toml.cpp:13:
In file included from ../src/v3.3.0-055894c820.clean/include/toml++/toml.h:69:
In file included from ../src/v3.3.0-055894c820.clean/include/toml++/impl/parser.inl:26:
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/fstream:950:9: error: use of undeclared identifier 'fseeko'
    if (fseeko(__file_, __width > 0 ? __width * __off : 0, __whence))
        ^
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/fstream:213:5: note: in instantiation of member function 'std::basic_filebuf<char>::seekoff' requested here
    basic_filebuf();
    ^
/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/fstream:1142:5: note: in instantiation of member function 'std::basic_filebuf<char>::basic_filebuf' requested here
    basic_ifstream();

I use meson to build tomplusplus, I investigate this error, this looks like doesn't support lower version of android, but I use the latest android SDK. Could someone help confirm this issue? Thanks in advance.
The similar issue: https://github.com/assimp/assimp/issues/4563
Steps to reproduce (or a small repro code sample)

Additional information

The compile error you're showing me is from a system header (fstream), not anything in toml++, so this is an Android SDK bug methinks.

The compile error you're showing me is from a system header (fstream), not anything in toml++, so this is an Android NDK bug methinks.

Yeah, this is an Android NDK bug, see https://android.googlesource.com/platform/bionic/+/master/docs/32-bit-abi.md#32_bit-and.
However, the error was triggered when include/toml++/impl/parser.inl of toml++ requested the system header file fstream.

However, the error was triggered when include/toml++/impl/parser.inl of toml++ requested the system header file fstream.

Yes? Not sure what you want me to do about it. It's a standard library header.

Yes? Not sure what you want me to do about it. <fstream> is a standard library header - every library that uses it will have this problem.

I submitted a PR to fix this.


Unable to type # and { characters in Windows version

All is in the title, it is impossible to type # or { characters in the style sheet, the only way I have found is to use copy/paste.

Windows 7 SP1 ... same error

@flemmens @gendronb
Do you have English US as keyboard language in your Windows system settings?
Or another language?
I'm able to type the missing characters when I switch keyboard language to English US

As the codemirror samples on the web all work with my German language setting, I suppose the characters get swallowed somewhere in the carto.css definition.
The key codes are different for different for different keyboard langugaes.
I've dug through Mapbox Studio and codemirror source, but wasn't yet able to find where this happens.
English US keyboard layout, key code for {:

German AT keyboard layout, key code for {:

I had an old version of Mapbox Studio and never noticed this problem. After being absent for a while I recently updated to 0.2.7. Now I can't type "{" or "[" in the style editor any more.
Mapbox Studio 0.2.7.
Windows 8.1 64bit
English US System language
Region German
German (IBM) keyboard
input on codemirror.net works fine.
Quite sad as this renders Mapbox Studio practically useless.

@stephankn There's a workaround, if you have a keyboard with a numeric keypad, you can use Alt codes to create the missing braces:

Press (and keep pressed) Alt
Type numeric code of character you want
Release Alt

Alt + 123 => {
Alt + 125 => }
Alt + 91 => [
Alt + 93 => ]

Progress report:

I concentrated on } (works) and { (doesn't work)
same problem exists with codemirror 5.3.0 (released yesterday)
somewhere/somehow the keypress event gets mangled/catched before codemirror can properly process it
even setting Chrome's Event Listener Breakpoints just getskeyup for { instead of keypress and input events, like for }
I removed every reference to carto mode and definitions, so that's ruled out as a cause
{ works with the online codemirror demos

I created a minimum testcase:
<html>
<head>
<script src="../ext/codemirror/codemirror.js"></script>
<link rel="stylesheet" href="../ext/codemirror/codemirror.css">
</head>
<body>
<script type="text/javascript">
	var myCodeMirror = CodeMirror(document.body);
</script>
</body>

to investigate KeyboardEvents.
Event for } (works) looks the same in minimum demo and in Mapbox Studio:

Event for { in minimum demo:

Event for { in Mapbox Studio:

Differences of events:

charCode: 0 vs. 123
keyCode: 55 vs. 123
keyIdentifier: U+0037 vs. F12
type: keyup vs keypress
which: 55 vs. 123

@flemmens @yhahn @springmeyer @gendronb @amyleew @stephankn
FINALLY!!!
After spending endless days (and some nights) on stepping through MapBox Studio and codemirror I found it.
The events for { and [ get swallowed by the shortcuts to switch between tabs.

That's what the sequence of events looks on my keyboard, when I press { (AltGr+7).

Because of keyCode 55 falling into the range (which > 48 && which < 58) Editor.prototype.keys returns false and thus property preventDefault of the keydown event gets set to true and thus the keypress event for { never fires.
  case ((which > 48 && which < 58) && ev.altKey): // 1-9
    var tab = $('#tabs a.tab')[(which-48)-1];
    if (tab) $(tab).click();
    break;

Quick fix (for an existing install)
Remove the above case statement (or adjust (which > 48 && which < 58) to not lose tab shortcuts), which can be found here:
https://github.com/mapbox/mapbox-studio/blob/c5c21df2b3442166bb7f82a68a60c86bac5f576e/app/style.js#L345-L348

Incredible work @BergWerkGIS!!!

Thanks :rocket:

Nice work @BergWerkGIS!!!

@amyleew thanks, :smiley: :smiley: :smiley:
Do you use tab shortcuts?
How many tabs do you have in an average project?
Do you think, people will have more than 6 and want to switch between them?

I never used tab shortcuts. Was not aware of them. Don't need them.
Avoiding hard-coded key-codes sounds like a good idea in general as long as you don't know what keyboard layout they might conflict with.
Is the following a possible solution?
http://www.w3.org/TR/DOM-Level-3-Events/#keys

@stephankn thanks, UI Events (formerly DOM Level 3 Events) might help. We will take a look.
Have you tried my suggested solution?
Does it work for you now?

I can confirm that after commenting out the last case block in style.js as you suggested keys work.
I just looked around that file and found some codes I thought they might be layout dependent.
Tried Ctrl + / which should open help and Ctrl + \ which is supposed to open settings,
Both didn't work. No big issue for me, but likely same root cause.
On German layout for "/" you press Shift+7. So That hot-key would be Ctrl+Shift+7
On German layout for "" you press AltGr+"ß" (same key that would produce with Shift a "?"). So that key would be Ctrl+AltGr+ß
No idea what key would produce code 191 or 220.

@stephankn thanks for confirming.
I've opened a new issue (#1380) to address this.


Fixed Epinio Tap (homebrew)

The Github action that we were using to update the official Formula is not working with third-party Taps.
This PR partially revert the https://github.com/epinio/epinio/pull/1996/files
This will keep the bump of our Epinio Tap (https://github.com/epinio/homebrew-tap/blob/main/Formula/epinio.rb) with the tag action. The official Homebrew-Core repository will still need to wait the official publishing of the release.

Codecov Report
Base: 57.58% // Head: 8.26% // Decreases project coverage by -49.33% :warning:

Coverage data is based on head (7faa863) compared to base (3ac51ba).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #2033       +/-   ##
==========================================
- Coverage   57.58%   8.26%   -49.33%
==========================================
  Files         179      93       -86
  Lines       14543   10118     -4425
==========================================
- Hits         8375     836     -7539
- Misses       5087    9227     +4140
+ Partials     1081      55     -1026

Flag
Coverage Δ

acceptance-api
?

acceptance-apps
?

acceptance-cli
?

unittests
8.26% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

How about instead of moving the brew activity from release-publish back to the goreleaser (in release)
using a custom goreleaser step in release-publish ? With a goreleaser config limited to just the brew thing ?

How about instead of moving the brew activity from release-publish back to the goreleaser (in release) using a custom goreleaser step in release-publish ? With a goreleaser config limited to just the brew thing ?

@andreas-kupries I thought about this option and I wasn't sure because of the availability of binaries built in the previous step. I guess we need to rebuild them again, so the goreleaser config will have also all the building stages, and we should remember to keep them aligned.
Having it after the tag but before the release will let us also test it before releasing it to the public. The Mac installation is simpler with brew.

How about instead of moving the brew activity from release-publish back to the goreleaser (in release) using a custom goreleaser step in release-publish ? With a goreleaser config limited to just the brew thing ?

@andreas-kupries I thought about this option and I wasn't sure because of the availability of binaries built in the previous step. I guess we need to rebuild them again, so the goreleaser config will have also all the building stages, and we should remember to keep them aligned.

Oh, the brew tap puts the actual binaries into the formula ? ... Ok, I suspect that you are right that this then requires the build section for the binaries. However all the images and manifests we should be able to cut out.
On the topic of keepng them in sync, I just checked, and goreleaser seems to support some kind of include system for the config: https://goreleaser.com/customization/includes/
That should allow us to have a single spec for the build section shared between the two places..

Unfortunately that's a Pro feature.. :/
Yes, the build part is not that much. I'm just worried about the actual release. The action will start after that we have published the Product Release. So I guess that goreleaser will create a new draft, or maybe it will draft the published release (?). Or maybe nothing. Not sure about the behaviour.
I don't have a strong opinion on this. It has pros and cons. We can say that we already know about the previous approach, and maybe we can try your proposal, and see what is going to happen. What do you think? :slightly_smiling_face:

Ok, let us go with your change now, that way we have something working. Then maybe experiment with my proposal.


Add support for documents

When sending a document this is the response, this adds a helper method like files and images have to get the document reference so we can download the attachment.

Tested as below, works well, can we get this merged in so i can update our package from pip ?

Hi @taylorgibb
Thanks for taking your time to contribute
Merging this

Thank you so much, much appreciated! Thanks for the work on this library as well!

@Kalebu any idea when you will be able to publish this to pip ?

There was no definite like circle to publish to PyPI but I will definitely do it this week
Have two questions ASAP

Does this pull request also fix issue #45
Do you also have spare time to work on #43?

Thank you @taylorgibb

Yes it does fix #45 but i suppose i should update the docs and the sample hook as well. Ill send a separate PR for that later today as there is not concept of message_type file anymore, Whatsapp is now sending them as message_type document.
I can take a look at #43, i just want to get our project over the line first.


Add box resizing to MD integrators

@mphoward this is a working implementation of box resizing for LangevinDynamics. It is throwing a ton of errors on the unit tests, but I'm not sure how polished vs hacky we want this to be for now.
Let me know how you'd like to proceed!

Found a small issue where there was no check on whether a barostat was set before applying the barostat logic. This caused an error when barostat=None.
This seems to be running well in the test case discussed. Ready for a review whenever you get a chance next week, @mphoward !

@mphoward I think this is all good and ready for use!


NEMO: Replace RPIO.GPIO with pigpio

We are no longer using the RPI.GPIO library for controlling the GPIO pins, for timing reasons.
I'm not sure how using two different libraries to control GPIO outputs would clash (if at all). If you have reason to believe it's not an issue - please let me know!
pigpio: http://abyz.me.uk/rpi/pigpio/python.html
pip3 install pigpio
The syntax between the two libraries are very similar.
With pi = pigpio.pi()
GPIO.setup(channel, GPIO.IN) is now pi.set_mode(channel, pigpio.INPUT)
GPIO.output(channel, GPIO.HIGH) is now pi.write(channel, 1)
etc...

Ok, I'll get the nemo code switched over to pigpio for GPIO access.
It looks like you're using both pigpio and busio for I2C, is there a preference which should be used for nemo?

I have a very slight preference for busio for Nemo's i2c because that's what most of our other sensors use. The only reason we're using pigpio for i2c is because of that specific driver's heritage.

Copy that, I'll stick with busio then.

Resolved in a5fad5a3c81f96b0495f382b54550d13f383a367


Clean up code coverage

Current coverage is 81.33% (diff: 100%)

Merging #24 into feature/0.3.0 will increase coverage by 25.60%

@@           feature/0.3.0        #24   diff @@
===============================================
  Files                 14         12     -2
  Lines                305        209    -96
  Methods              199        199
  Messages               0          0
  Branches               1          1
===============================================
  Hits                 170        170
+ Misses               135         39    -96
  Partials               0          0

Powered by Codecov. Last update 92aa46c...0197cbf


⚠ Bofrost.lu has degraded performance

In bf84835, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1213 ms

Resolved: Bofrost.lu performance has improved in 2a9811d after 29 minutes.


typescript definition?

Is there a typescript definition available for this?

Unfortunately not and we have no plans for supporting one in the near future.


Unclear what PermissionError does

It's unclear what PermissionError does. The docs say:

Geocoding operation failed because of a permission error.
Either the user denied the permission, or the permission was denied forever.

But that's already what PermissionDenied is for. It even has a forever boolean.
So let's look at the code. It's caused by either one of these exceptions:

PermissionMissingException

This isn't used at all, thus it can simply be deleted.

PermissionRequestException

This only happens when the WeakReference requester is null at ActivityProvider. Seems like very much an unexpected error.

I would delete PermissionMissingException, PermissionRequestException and the entire PermissionError. In order to do so, I would throw an IllegalStateException in ActivityProvider instead. This makes your library quite a bit easier: right now it's quite confusing to see the difference between PermissionError and PermissionDenied.

I agree, again this is a case of an earlier design of the libraries API requiring this. Then getting refactored away later on.


Add option to skip cleanup after verification run

Skip cleanup flag added to command line and passed to the chart testing to skip resource cleanup after verification run
Closes #330

Thanks @dcurran90!


Clarification of requirements on the attributes of a bounds variable

Clarification of requirements on calendar attribute of a bounds variable
Moderator
None at present
Moderator Status Review [last updated: 2020/05/07]
Just posted
Requirement Summary
Express clearly what constitutes a valid value for the calendar attribute of a bounds variable.
Technical Proposal Summary
Clarify the text in Section 7.1 expressing the requirement for equivalence of attributes between bounds and associated coordinate variables.
Benefits
People using the CF convention to describe coordinate bounds.
Status Quo
In Section 7.1 of the current standard it is stated that the calendar attribute of a bounds variable, together with other listed attributes, "must always agree exactly with the same attributes of its associated coordinate". This appears clear, but there is some ambiguity because noleap and 365_day values for the calendar attribute have exactly the same meaning. Some CMIP6 data, for example, has been provided with time coordinates using one form and the bounds variable using the other.
Does the reference to exact agreement in the standard mean agreement in string value, or agreement in meaning?
The other attributes referred to in the same sentence are units, standard_name and positive. The same issue could arise with the units attribute, in that it is possible, in many cases, to express the same logical unit with a range of different string values.
I do not have a strong preference here .. but it appears simplest, both in terms of the structure of the standard and the keeping things simplest for users, to insist on an exact match of the attribute values.
Detailed Proposal
Replace "must always agree exactly with" with "must exactly match the values of".

Hello Martin,
The intention, as I recall, was for agreement in meaning, rather agreement in the the exact strings, but that intent clearly didn't make it into the text.
If people agree, I would suggest the addition of some suitable wording to make this clear would make this a defect, rather than an enhancement.
Thanks,
David

Control attributes are fully redundant on bounds variables.  The current standard already recommends against them, in two places.  Why not simply deprecate them, rather than adding new requirements?

@davidhassell : OK, I'd be happy to treat this as a defect issue -- do you recall where the intention you refer to was discussed? Or who was involved?
@Dave-Allured : I'm not sure why the original choice was made. It would certainly be simpler to ban these attributes on bounds variables, but doubt that it justifies changing the status-quo.

The original discussions took place on Trac ticket 140 (https://cf-trac.llnl.gov/trac/ticket/140), which was accepted for inclusion into CF-1.7. I'll mark this issue as a defect for now.
Deprecating (rather than banning) these attributes is, of course, possible, but I don't feel there is a use case for it at this time. I wonder if there are use cases for bounds variables having, for example, different but equivalent units, or for bounds variables being used independently of their parent coordinate variables (in which case having units, names, etc could be useful). In any event, that perhaps is a discussion for a separate issue, if anyone wants it.

Hi @davidhassell : thanks.
There is a use case for providing attributes on bounds variables in the Trac ticket which you cited (140) : @taylor13 describes a usage where the user needs to know the units of the bounds variable and does not make use of the parent coordinate variable. However, the more important point, I think, is that the status quo is clearly that use of these attributes on the bounds variables is clearly deprecated and not forbidden. Changing that would, as you say, be a discussion for another issue.
@JonathanGregory , @taylor13 : can you help with the interpretation of the intention of the discussion in Trac 140 on the precise rule for calendar attributes on bounds variables? In particular, if a variable has calendar = noleap, would calendar = 365_day on the bounds be:

(A) deprecated as being the same but redundant or
(B) forbidden as being a different string (not exactly the same, even though it has exactly the same meaning)?

Evidently we didn't think of this problem. As far as I remember, I had in mind that the strings would have to be exactly the same (B), because it's simpler to check and consistent with them not being needed anyway, which is why they're deprecated in general.

OK - are these the three choices, then (in no particular order)?
i) Drop the  word exactly from
"must always agree exactly with the same attributes of its associated coordinate, scalar coordinate or auxiliary coordinate variable" (7.1)
as rectifying a defect.
ii) Keep the word exactly but clarify it to mean "exact string match". This is also rectifying (a different) defect.
iii) Drop the word exactly from the sentence as an enhancement.

Reconsidering, and after briefly reviewing Trac 140, I favor a fourth choice:
iv)  Martin's original wording, "must exactly match the values of", with no further changes.  This rectifies a defect.
To me this is simple and sufficient.  @davidhassel, I understand what you are trying to clarify in (ii) above, but I think the extra wording is not needed.
I retract my earlier comment about deprecating "control attributes".  My true preference is to fully ban interpretive attributes on bounds variables, on the rationale that they are only an extension of the parent.  This has been said before.  But that is outside the scope of this ticket, so I will drop that for now.

@davidhassell : David A. and Jonathon are both in favour of requiring an exact string match (my option (B), your option (ii)).  Are you happy with this interpretation?
I agree with Jonathon that this is preferable in order to preserve clarity in the file metadata.

I don't particularly like the idea of insisting on "exact string match", because it is contrary to how the rest of CF works. For example, if output from one instrument has a data variable with units of 'watt' and the output from a model has a comparable data variable, in the same netCDF file, with units of 'meter^2-kilogram-second^-3', then that is fine, even though it may lack clarity for the user.
I think that it would useful to recommend that exact string matches are used, for clarity, but not to insist on it.

Dear @davidhassell
I agree that exact string match is unlike the rest of CF. It seems OK and appropriate to me in this case because providing exactly the same string is the nearest thing to not providing any string, and thus taking the default i.e. the value on the coordinate variable. It is transparent and easy to check that the attribute on the bounds is giving the same information if it must be the same or absent. I think that we would be better off if we had not allowed attributes on bounds variables.
However, you could argue there was a purpose or advantage in allowing a different string that meant the same. That would be an enhancement, as you say, for which we need a convincing use-case.
Best wishes
Jonathan

@davidhassell, please consider that bounds variables are unique in relation to ordinary data variables, thus the analogy to instruments with equivalent unit strings is not a very good comparison.  A bounds variable should be nothing more than a close extension of the parent coordinate variable.  Its only purpose is to provide explicit cell boundary values for each coordinate value.
A better analogy would be to actual_range attributes.  By their structure alone, these can not have their own independent interpretive attributes, and always inherit from the parent.  I see bounds variables in the same light.
IMO the practice of varying attribute string values on bounds should be discouraged or prohibited, thus I favor the original intent to prohibit non-exact string values.  The message to dataset creators should be simply, "Don't do this."

Hello @JonathanGregory  and all,
I don't have a use case for allowing a different string that means the same, and agree that providing exactly the same string is the nearest thing to not providing any string.
Therefore, I'm happy to agree with the the "exact string match" interpretation.
Thanks,
David

There seems to be a consensus.  Please review my suggested changes in the above PR.  Note that for consistency, I expanded this to all functional attributes on boundary variables, not just calendar.

Apologies, I made a github newbie mistake and failed to squash my commits.  Please review changes in the next PR to follow.  They will be easier to read.

To be sure, is the change in text backward compatible or will it make some datasets that were considered conformant with CF now non-conformant? (nb.  It is stated in https://github.com/cf-convention/cf-conventions/issues/265#issue-614215549 that "Some CMIP6 data, for example, has been provided with time coordinates using one form and the bounds variable using the other.")

I assume that @martinjuckes meant that some CMIP files might say noleap and others 365_day. I don't think he meant that there are existing files in which  noleap was used on the coordinate variable and 365_day on the bounds, for example, but he was concerned that this might currently be allowed. This proposal would disallow it. If there are any such datasets, they would be invalidated by the next version of the conventions, but not by the version they were written with, of course. In general we don't like even this sort of backward-incompatibility but I think it's harmless in this case. If software chose to rely on the new convention and assume that the bounds had the same calendar as the coordinates without checking, the outcome would still be OK if it's equivalent although not exactly the same string.

Dear @Dave-Allured
Thanks for the text. I have a couple of comments.

I suggest omitting the word "functional", which occurs twice. It's not obvious (to me) what it might mean exactly, and I think that really you're defining what it means by going on to describe the two groups concerned. The word "functional" therefore doesn't add any information but might puzzle the reader.

You mention long_name as an example but it's not one of the attributes "controlled" by this restriction. The reader might wonder about it. Perhaps it would be better not to mention long_name in this paragraph. We could add a final paragraph, after formula_terms, to say something like, "Other attributes not mentioned above, such as long_name, may have different values for the coordinate and boundary variable, if present on both."

Jonathan

Um, @martinjuckes did literally say there are existing files with this conflict.  First paragraph under Status Quo above:  "Some CMIP6 data, for example, has been provided with time coordinates using one form and the bounds variable using the other."
Presumably such files are labeled as Conventions = CF-1.8 or earlier.  So I agree, they are technically conformant because of this label, but would be non-conformant if re-labeled to a later CF version.
My strict wording of this requirement was intentional, based on the discussion up to this point.

Hi @Dave-Allured , @JonathanGregory  : Dave is right, the main motivation for raising this was to see if something of the form:
double time(time) ;
   time:bounds = "time_bnds" ;
   time: calendar = "noleap" ;
double time_bnds(time,nb) ;
   time_bnds: calendar = "365_day" ;

should be considered as valid. My interpretation of the status quo is that the convention is ambiguous, so I don't personally think that a clarification would break with backward compatibility.
The strict interpretation, treating the above as an error, is in line with the current behavior of the cf-checker, which is how I became aware of the CMIP6 files which contain this syntax.
@Dave-Allured : the last sentence in the 2nd paragraph (line 14) of your text reads "Their data types do not need to be an exact match." I think that "Their" refers to the parent variable and the bounds variable, but grammatically, as written, it appears to refer to the attributes. It might be clearer if placed at the end of line 12?

@JonathanGregory, thanks for the feedback.  Your help with the wording is appreciated.
I thought the term "functional attributes" might be understood from context.  I was looking for a short collective term that means "attributes that are functionally active in the CF interpretation of the variable".
On review, I notice that the original sentence in CF-1.8 is kind of puzzling in its own way.

Boundary variable attributes which determine the coordinate type (units, standard_name, axis and positive) or those which affect the interpretation of the array values (units, calendar, leap_month, leap_year and month_lengths) must always agree exactly with the same ...

Is it appropriate here to explain distinction between the first and second groups?  What is the best way to describe the general intention here, yet try to remain concise?
For the purpose of this section, I think we only care about indicating which attributes are significant in some way to CF interpretation and processing.  Let me tentatively merge the two groups, because the distinction may not be locally relevant, and try this simplified wording without "functional":

Boundary variable attributes which are significant to CF interpretation (units, standard_name, axis, positive, calendar, leap_month, leap_year and month_lengths) must always agree exactly with the same ...

Do you like this, or have another suggestion?

@JonathanGregory said:

You mention long_name as an example but it's not one of the attributes "controlled" by this restriction. The reader might wonder about it. Perhaps it would be better not to mention long_name in this paragraph. We could add a final paragraph, after formula_terms, to say something like, "Other attributes not mentioned above, such as long_name, may have different values for the coordinate and boundary variable, if present on both."

I added a new short paragraph for this, and expanded a little.  Check out this commit: https://github.com/Dave-Allured/cf-conventions/commit/44fcdb128860d963a5ed1ccb0cf8fca1f345d98e
I preserved the opening sentence because it was a general introduction to the concept, and also it was inherited like this from the original in CF-1.8.

@martinjuckes said:

... the last sentence in the 2nd paragraph (line 14) of your text reads "Their data types do not need to be an exact match." I think that "Their" refers to the parent variable and the bounds variable, but grammatically, as written, it appears to refer to the attributes. It might be clearer if placed at the end of line 12?

Okay, how about this?  I like the flow of concepts as it is now, but this fixes the improper pronoun.  https://github.com/Dave-Allured/cf-conventions/commit/4268d30fd3fbd2f39e548c3d8dcf4542528c917a

@Dave-Allured : Could you say "The variable data types ....." instead of "The data types .....". As it stands, it could be read as a statement about the data types of the attributes.

@martin, actually this is a statement about the attributes, not the data variables.  How about this?  https://github.com/Dave-Allured/cf-conventions/commit/852bfdcb542d3e1d55591e29c2955d8477bcf91c

Dear @Dave-Allured
I would like this wording which you suggested, "Boundary variable attributes which are significant to CF interpretation (units, standard_name, axis, positive, calendar, leap_month, leap_year and month_lengths) must always agree exactly with the same ...". I think that's a good definition of why we're concerned with them, and I don't see a need to distinguish the groups.
I like your long_name paragraph, but I think it would be better after the formula_terms paragraph. I feel we should say, "These ones must be like this, these other ones like that, and all the rest it doesn't matter" rather than putting all the rest in the middle.
Best wishes and thanks
Jonathan

@JonathanGregory, I reworded along these lines.  https://github.com/Dave-Allured/cf-conventions/commit/ad27ae4febd4f6bb9aaa6e72ebd223cb55b03efe
After many rounds, I settled on "Attributes which affect the interpretation of values" for a single collective description of those active attributes.  It's not perfect but I think it will suffice.
I enhanced some wording in the third paragraph concerning purely descriptive attributes such as long_name.  However, I did not want to move it below formula_terms as you requested.  Notice that formula_terms is not a simple paragraph, but rather a longish subsection with two paragraphs and a long formula_terms code example.   The second and third paragraphs of 7.1 together (current rev), make up a good and consistent introduction to the whole topic of boundary variable attributes.  Therefore I feel that this "purely descriptive" third paragraph is best coupled with the second paragraph, and would be somewhat lost if it were moved below the entire formula_terms subsection.  Think of it as dealing with the simple cases first, and leaving the complicated one for last.
Further suggestions are welcome.

Further simplification of third paragraph:
https://github.com/Dave-Allured/cf-conventions/commit/ad27ae4febd4f6bb9aaa6e72ebd223cb55b03efe

Sorry, wrong link.  Further simplification of third paragraph:
https://github.com/Dave-Allured/cf-conventions/commit/31ca211f6e21dcea6082912eb67897511f55d725

@Dave-Allured : Sorry, I misunderstood that bit about data types. You mean that the convention should accept having, for instance, calendar as a string variable on the main variable and a character array on the bounds variable? This looks likely to cause confusion, as some software may consider them as different. Wouldn't it be better to at least recommend that they have the same data type?

@martinjuckes, yes, string vs. character, that is a good example of what I mean by compatible.

Data types of the duplicated attributes do not need to match, but must be compatible for comparing values.

I think this is needed for a complete answer to the original question of agreement between coordinate and boundary attributes.

@martinjuckes asked:

This looks likely to cause confusion, as some software may consider them as different. Wouldn't it be better to at least recommend that they have the same data type?

I actually had exact type match in one of my drafts, then thought about it and changed to simple compatibility.  If type match is either required or recommended, this adds responsibility and complexity on both data creators and conformance checkers.  Much existing software provides easy comparison between mixed types.  Some software goes a step further and reads netcdf input to generalized types, such as ingesting both string and character as undistinguished  internal strings.  E.g. NCAR's own NCL language, ever since the addition of the new netcdf type string.  I think the cost of exact type match exceeds any benefit.
Also I think this draft statement of type compatibility merely clarifies the status quo for CF policy on data type of boundary var attributes.
Further thoughts?

Dear @Dave-Allured
I think think this is fine, thanks very much, except there shouldn't be a comma between the parenthesis and "should be inherited".
Best wishes
Jonathan

Fixed, thanks.  Also one other minor grammatical improvement.  https://github.com/Dave-Allured/cf-conventions/commit/f8d7a28a66ac4c4ac33a47bdd7462e4e68b5e434

@Dave-Allured : OK, thanks for the clarification on data types

Summary and request for consensus.
I propose to move this pull request forward under Rules for CF Conventions Changes.  Here is a summary of the current proposal.  See the PR itself for full text of changes.

Changes to the first part of CF section 7.1, Cell Boundaries.
On boundary variables, require exact value match with the parent coordinate variables, for CF defined attributes which affect the interpretation of values.
Also clarify requirements for data types of such attributes.

For full consensus, support is needed from at least two members of the conventions committee, and at least one other contributor.   Please indicate your vote for support or dissent at this time, until we have the minimum necessary votes.  The vote is open to all interested persons.  I vote +1 in support.
If there is full support and no dissent or new change requests, I will finalize the pull request and send it to CF master after the three week waiting period.
Votes and further comments should be sent to this CF issue #265.

On review I found other attributes that are missing from that list of CF active attributes.  This is getting cumbersome.  So I generalized the list by adding the fuzzy prefix "such as", so that unpredicted cases would be included:  https://github.com/Dave-Allured/cf-conventions/commit/ea5994bf15786e9dc81ccfbb013830698ccd65ca
I figure this is not controversial, but who knows.  Call for votes is still active, unless there are further change requests.

Dear @Dave-Allured
Which other attributes are "active"? It would be best to spell them out. I don't think it's too much to be cumbersome. Another way (but more work for you) would be to add some indication to the relevant attributes in Appendix A, instead of listing them explicitly here. That would make the text more future-proof, probably.
I'm still definitely in favour of this proposal! Thanks
Jonathan

@JonathanGregory, I don't agree.  You are asking for robust enumeration for a redundant data feature that is recommended against using.  This has already been cumbersome for building the current draft.  There will be extra work to examine the several dozen other possible cases in Appendix A.  Then there will be added future responsibility to check for boundary attribute conflicts whenever a coordinate attribute is newly added or adjusted.  I also think adding a new notation in Appendix A is not appropriate.
So I think a new precedent is needed.  I think we need to explain these potentially conflicting duplicate attributes by description, not by enumeration.  As a start, I wonder whether you find acceptable my current wording, using the device of "such as" to generalize and convert the following into simply a list of examples.

Hello @Dave-Allured, @JonathanGregory and all,
I agree with @JonathanGregory  - spelling out the "active" attributes in the appendix A table is a good idea. As long as it's permissable, software providers and data creators will need to be able to unambiguously know the exact list of active attributes, and the "such as" list in the text doesn't really do that, I feel. If we don't know what they are, it is likely that others won't, either! I suspect readers would see the "such as" list, but not then check the rest of the conventions for any other attributes they're not aware of that might be active.
If this is flagged in appendix A, then it is guaranteed that any new attributes will be considered for activeness, as when they are added to table in Appendix A, the author will see the "Active" column, and be forced to put in a value. It is more likely that a list embedded in the text (like we had in 1.8) would be overlooked.
I propose this rewording:
Since a boundary variable is considered to be part of a coordinate variable's metadata it is generally not necessary to provide it with attributes, as the boundary variable  is assumed to inherit all of the attributes of its parent coordinate variable (with the exception of the formula_terms attribute). When a bounds variable attribute is provided, it takes precedence over any inherited value. However, when duplicating "active" attributes which affect the interpretation of values (such as units and standard_name, see Appendix A for the complete list of active attributes described by this standard), their string or numeric values must be exactly the same as the parent variable attributes.  Data types of these duplicated attributes do not need to match, but must be compatible for comparing values. Duplication of such active attributes on the boundary variable is permissible but not recommended.
Then the next short paragraph ("Purely descriptive attributes which do not affect interpretation ...") is not needed.
Thanks,
David

Thank you both for your comments. @Dave-Allured asks whether "such as" with examples is "acceptable". It feels harsh to say "No, it's unacceptable", but I'd really prefer us to specify them. You do have text which describes the characteristics of the variables concerned, and that's fine, but it's safer for the convention also to say explicitly which ones they are, since people using the convention would probably not always make the same decision. As @davidhassell shows, it doesn't make the text more complicated. If anything, it's a simplification.
I'd like to suggest a further rewording, to avoid introducing "active" as a CF jargon word, and put things in a slightly different order:

Since a boundary variable is considered to be part of a coordinate variable's metadata it is generally not necessary to provide it with attributes, because the boundary variable is assumed to inherit all of the attributes of its parent coordinate variable (with the exception of the formula_terms attribute, which may be required, as described in the next paragraph). It is recommended not to include any attribute on a bounds variable which affects the interpretation of values (such as units and standard_name, see Appendix A for the complete list of such attributes), and it is permitted to include such an attribute only if its string or numeric value is exactly the same as the parent variable's attribute. The data types do not need to match, but must be compatible for comparing values. If any other attribute is provided on a bounds variable, it takes precedence over any corresponding attribute of the parent variable.

Which are the attributes concerned, apart from units standard_name axis positive calendar leap_month leap_year month_lengths, which @Dave-Allured has identified? Looking at Appendix A, I am unsure, so I think we do need to decide. Probably computed_standard_name should be in that list as well. Is it required that bounds must be packed in the same way as their parents with add_offset and scale_factor? Must they have the same valid range, missing_value and _FillValue? Do cf_role compress geometry nodes have any CF meaning for a bounds variable? Looking at all these, I incline more strongly than before to thinking we should add this to Appendix A. In the existing Use column, we could add an indicator for those coordinate variable attributes (marked as C) which are allowed but deprecated and must agree with the coordinate variable, and those which are allowed and may be different from the coordinate variable, such as long_name. It would be clearest if every C attribute was put in one of these two categories, except formula_terms, which has special rules.
Jonathan

Dear @JonathanGregory ,
Thanks - I like you suggested text. The other attributes you mention might suggest different wording, though. My initial thoughts on those attributes:
I would say that add_offset, scale_factor, valid _*, missing_value, and _FillValue should not be inherited from a parent coordinate variable, because they relate only to packing and encoding choices which do not affect the physical interpretation of the bounds. These might reasonably be different to the parent coordinate variable, as the bounds can be much larger.
compress is trickier still, as whether or not it should be inherited depends on whether or not the bounds variable is compressed by gathering, or not (which reminds of https://github.com/cf-convention/cf-conventions/issues/147). I would say that it is also not inherited, so if the bounds variable are compressed by gathering then it carries its own compress attribute.
I reckon cf_role is inheritable, and should have the same value as the parent, if provided.
bounds and nodes are also non-inheritable, as all they do is name the bounds variable itself.
I think geometry is only specially defined for data variables (and so Appendix A has  defect in suggesting otherwise!)

Missing data is disallowed in coordinate variables.   (First paragraph of section 2.5.1.)  Do bounds variables inherit that restriction as well?  I would presume so, but maybe someone has a counter-example.  Either way, it may be worth spelling out explicitly.
In any case, I think there shouldn't be any missing_value and _FillValue attributes on coordinate variables to inherit, since they would be superfluous at best.  Is that something that should be mentioned as a best practice?

Hi @sethmcg, you are right that missing data is disallowed in coordinate variables, but it is for auxiliary coordinate variables.
The bounds may have missing data where the parent auxiliary coordinates do not (grid cells with a varying number of cell bounds #163).
Is it possible for the opposite to occur, i.e. the auxiliary coordinate is missing but the (some of) its bounds are not?

Hi all,
I'm still re-assimilating what went on here, but it occurs to me that allowing data type equivalence (rather than equality)  is problematic:

The  missing_value and _FillValue (and the valid_* attributes) must be of the same data type as the data to which they apply, so if they these attributes are inherited, then the bounds must be of the same data type.

If the bounds are strings and the coordinates chars, then the bounds will not have the extra dimension, as is currently required: "A boundary variable will have one more dimension than its associated coordinate or auxiliary coordinate variable.". (This is easily dealt with via a caveat, of course.)

Although most software does support type casting, it is not always done in the same way (for example, in Python the  default  type casting rules of numpy have recently changed), and even if it is done as expected, the  recast numbers may produce undesired results in ways that may  be hard to detect.

Thanks,
David

Dear all
It would be good if we could conclude this issue, about the attributes of bounds variables, because it has been open for a long while. Considering the previous discussion, I propose the following wording (a revised version of earlier text), to replace the last sentence of the first paragraph of sect 7.1 ("Since a boundary variable ...") and the whole of the next paragraph ("Boundary variable attributes which ..."):

A boundary variable inherits the values of some attributes from its parent coordinate variable. If a coordinate variable has any of the attributes marked "I" (for "inherit") in the "Use" column of Table A.1, they are assumed to apply to its bounds variable as well. It is recommended not to include any of these attributes on a bounds variable. If such an attribute is included, its data type and its value must be exactly the same as the parent variable's attribute.

A bounds variable may have any of the attributes marked "O" for ("own") in the "Use" column of Table A.1. These attributes take precedence over any corresponding attributes of the parent variable. In these cases, the parent variable's attribute does not apply to the bounds variable, regardless of whether the latter has its own attribute.

It is recommended that a bounds variable should not have any attribute which is not marked either "I" or "O" in the "Use" column of Table A.1, even if it can be an attribute of the parent coordinate variable (those marked "C").

The "I" attributes are axis calendar cf_role computed_standard_name leap_month leap_year long_name month_lengths positive standard_name units. The "O" attributes are actual_range add_offset compress formula_terms missing_value scale_factor valid_max valid_min valid_range _FillValue. "C" attributes which are neither "I" nor "O" are bounds climatology nodes. geometry should not be marked "C" (that's a defect).
Although this began as a defect, I think that adding new "Use" values for attributes (for which some support was previously expressed) is an enhancement, so I'm changing the label. I hope that doesn't slow down the conclusion! What do you think?
Best wishes
Jonathan

Jonathan, those changes look good to me.  I need to retire from this particular discussion, and abandon my pull request.  Also I think this issue #265 should be re-titled to something like "Clarification of attributes on bounds variables".  Best wishes for a good resolution.

Thanks, @Dave-Allured. I have generalised the title, as you suggest.

P.S.  Whomever picks this up, this should be obvious, but please feel free to copy all any or draft wording out of my old pull request.

Hello,
Thanks for new text, Jonathan, which I like, but wonder if the I and O system could be simplified. Would it work to say that all attributes already marked C are inherited by bounds variables, but any bounds variable attribute that is also marked B overrides that inheritance? Then we only need one new usage type (B) on a smaller number of attributes.
Should compress be in the listed of "owned" bounds variable attributes? It can only appear on a coordinate variable that contains indices.
The new text doesn't mention that the bounds variable must be of the same data type as it's parent coordinate variable. Am I right in thinking that that was agreed?
Thanks,
David

Dear David

[I] wonder if the I and O system could be simplified. Would it work to say that all attributes already marked C are inherited by bounds variables, but any bounds variable attribute that is also marked B overrides that inheritance? Then we only need one new usage type (B) on a smaller number of attributes.

Actually, in my text, which I think is consistent with the discussion, there is no situation where the bounds attributes overrides the parent attribute. If it's inheritable, it should be omitted, and if included it must be exactly the same as the parent, so it's not overridden, just repeated. If it's not inheritable, and not present, it's undefined for the bounds, rather than inherited.
I think two new "Use" values are needed (rather than one) because there are three situations to distinguish. As well as the two just mentioned, there is also a group of attributes which should not be used for bounds, because they are inappropriate.

Should compress be in the listed of "owned" bounds variable attributes? It can only appear on a coordinate variable that contains indices.

As you said in your earlier comment, compress should be included only if the bounds are compressed. Hence, it can't be inheritable, because it would be implied to apply the bounds if it wasn't included as a bounds attribute, and that's not necessarily right. Hence it must be an "own" attribute. However, it's unusual because the "own" attribute, if present, must be identical to the parent attribute!

The new text doesn't mention that the bounds variable must be of the same data type as it's parent coordinate variable. Am I right in thinking that that was agreed?

Yes, it was agreed, and that's what the first paragraph says. "If such an attribute is included, its data type and its value must be exactly the same as the parent variable's attribute."
Best wishes
Jonathan

Having had a very useful offline conversation with Jonathan, I now see that some of my suggestions weren't at all right, for which apologies. Specifically, my suggestion about "B" usage type in appendix A, and my comments on the data type of bounds variable.
We did, however, also come up with a changes to the proposed text.

The last sentence ("It is recommended that a bounds variable should not have any attribute which is not marked either "I" or "O" in the "Use" column of Table A.1, even if it can be an attribute of the parent coordinate variable (those marked "C")"  is not needed, as this notion is taken as read for all variables of all types.

The usage categories should be BI and BO, instead of "I" and "O" respectively, to highlight these categories relate to boundary variables.

We should disallow an inheritable attribute (BI) being set on the bounds variable but not on the parent coordinate variable.

The compress attribute should should not be in the BO selection, as it is only standardised for list variables used in compression by gathering.  Whilst the list variable and its dimension have the same name it is not a coordinate variable in the CF sense, so C type attributes like bounds are not meaningful. We should mention something about this in section 8.2 Lossless Compression by Gathering.

The proposal then could then become (new text in bold)

A boundary variable inherits the values of some attributes from its parent coordinate variable. If a coordinate variable has any of the attributes marked "BI" (for "inherit") in the "Use" column of Table A.1, they are assumed to apply to its bounds variable as well. It is recommended not to include any of these attributes on a bounds variable. If such an attribute is included, its data type and its value must be exactly the same as the parent variable's attribute. A boundary variable can only have inheritable attributes if they are also present on its parent coordinate variable.
A bounds variable may have any of the attributes marked "BO" for ("own") in the "Use" column of Table A.1. These attributes take precedence over any corresponding attributes of the parent variable. In these cases, the parent variable's attribute does not apply to the bounds variable, regardless of whether the latter has its own attribute.

The "BI" attributes are axis calendar cf_role computed_standard_name leap_month leap_year long_name month_lengths positive standard_name units. The "BO" attributes are actual_range add_offset formula_terms missing_value scale_factor valid_max valid_min valid_range _FillValue.

For the compression by gathering sissue, I suggest appending to the second paragraph in section 8.2 Lossless Compression by Gathering, new text in bold:

The list is stored as the coordinate variable for the compressed axis of the data array. Thus, the list variable and its dimension have the same name. The list variable has a string attribute compress, containing a blank-separated list of the dimensions which were affected by the compression in the order of the CDL declaration of the uncompressed array. The presence of this attribute identifies the list variable as such. The list, the original dimensions and coordinate variables (including boundary variables), and the compressed variables with all the attributes of the uncompressed variables are written to the netCDF file. The uncompressed variables can be reconstituted exactly as they were using this information. Note that even though the list variable and its dimension have the same name, it is not acting as a coordinate variable, and so can not be associated with a boundary variable.

Thanks,
David

Dear David
Thanks for the discussion and for making the text simpler and better.
Regarding section 8.2, I don't think we can say it's not a coordinate variable, because formally it is one, and the paragraph you've quoted begins by saying that it is. I'd suggest we avoid this by not giving a reason for the prohibition. Instead of your bold sentence, I'd propose a shorter one: "The list variable must not have an associated boundary variable."
Best wishes
Jonathan

Thanks, Jonathan - your text for 8.2 is much better. In full we have:

The list is stored as the coordinate variable for the compressed axis of the data array. Thus, the list variable and its dimension have the same name. The list variable has a string attribute compress, containing a blank-separated list of the dimensions which were affected by the compression in the order of the CDL declaration of the uncompressed array. The presence of this attribute identifies the list variable as such. The list, the original dimensions and coordinate variables (including boundary variables), and the compressed variables with all the attributes of the uncompressed variables are written to the netCDF file. The uncompressed variables can be reconstituted exactly as they were using this information. The list variable must not have an associated boundary variable.

Hello - unless there are any objections, I shall write up these agreed changes in a PR, with the aim of meeting the CF-1.11 deadline.
Thanks,
David

Hello @martinjuckes, @Dave-Allured, @JonathanGregory, @taylor13, and @sethmcg,
As participants in this conversation, it would be great if you could look at the associated PR #467 and confirm if you are happy with it (or not). The deadline for getting changes into CF-1.11 is Monday 13th November 2023 (i.e. 3 weeks before the expected release date of 4th December), so if you are able to look at it please do so soon.
We welcome, of course, a review from anyone else who is interested.
Many thanks,
David

I support the changes suggested.  A couple questions regarding the text:
I had trouble understanding the last sentence regarding inherited attributes.  I would suggest reordering the information in the last two sentences. Is the following better?

A boundary variable inherits the values of some attributes from its parent coordinate variable. If a coordinate variable has any of the attributes marked "BI" (for "inherit") in the "Use" column of Table A.1, they are assumed to apply to its bounds variable as well. It is recommended not to include any of these attributes on a bounds variable, but it is technically not forbidden to include a BI attribute as long as it is also present in the parent coordinate variable.  If such an attribute is included, its data type and its value must be exactly the same as the parent variable's attribute (i.e., there must be an exact match).

I also found it odd that we even mention bound variables in conjunction with list variables.  Aren't list variables invariably integer pointers to where the defined values of an array should be inserted into an array, skipping the elements that are missing?  Why would indices of anything have bounds?  If I understand this correctly, I'd rather we not muddy things by mentioning boundary variables here.
That being said,  I support the proposal no matter what the wording.

Hi @taylor13,
Thank you for the review. I like your suggested change to chapter 7 ("It is recommended not to include any of these attributes on a bounds variable, but it is technically not forbidden to include a BI attribute as long as it is also present in the parent coordinate variable"), and will put it into the PR.
On list variable bounds, you are indeed right that bounds are nonsense, but currently the conformance checker has no rule on enforcing this, so we need to make it clear in the text.

I realise that I missed a bit of Karl's suggested text ("(i.e., there must be an exact match)"). I'd like to suggest a rewording around that:

If such an attribute is included then it must match exactly the parent variable’s attribute, i.e. the data type and value must be exactly the same.

Dear @davidhassell, Karl @taylor13 et al.
I support the intention and would like to suggest some further small changes to words.
I feel that it's not clear whether the "Use" sentence in Appendix A is talking about variables or attributes:

The "Use" values are G for global, Gr for applying to groups, C for variables containing coordinate data, D for data variables, M for geometry container variables, Do for domain variables, BI for  for attributes inherited by boundary variables, BO for attributes owned by boundary variables, and - for variables with a special purpose.

I propose:

Each attribute may be used in any of the ways shown in its "Use" entry. G indicates it can appear as a global attribute, Gr as a group attribute, and all others as an attribute of a certain kind of variable, as follows: C for variables containing coordinate data, D for data variables, M for geometry container variables, Do for domain variables, BI for boundary variables when the attribute is inherited from the parent variable (which must have an exactly matching attribute, so the boundary variable attribute is redundant), BO for boundary variables when the attribute is owned by the boundary variable (and it is irrelevant whether the parent variable has such an attribute or what its value is), and - for variables with some other purpose.

In Chapter 7, I propose that we remove some duplication, and the word "technical", which I don't think makes the text clearer, and that we should use the phrase "boundary variable" consistently:

A boundary variable inherits the values of some attributes from its parent coordinate variable.
If a coordinate variable has any of the attributes marked "BI" (for "inherit") in the "Use" column of <>, they are assumed to apply to its bounds boundary variable as well.
It is recommended not to include a BI attribute of these attributes on a bounds boundary variable, but it is technically not forbidden to include a BI attribute provided that as long as it is also present in the parent coordinate variable and that it exactly matches If such an attribute is included then it must match exactly the parent variable's attribute, i.e. the data type and value must be exactly the same.
A boundary variable can only have inheritable attributes if they are also present on its parent coordinate variable.
A bounds boundary variable may have any of the attributes marked "BO" for ("own") in the "Use" column of <>.
These attributes take precedence over any corresponding attributes of the parent variable.
In these cases, the A parent variable's BO attribute does not apply to the its bounds boundary variable, regardless of whether the latter has its own attribute.

Best wishes
Jonathan

Dear @JonathanGregory .   I think your text is an improvement.   I might further tweak the following:
In Appendix A, REPLACE your suggested text with:
WITH:  Each attribute may be used in any of the ways shown in its "Use" entry.  G indicates it can appear as a global attribute, and Gr as a group attribute; if use of an attribute is restricted to certain kinds of variables this is indicated as follows: C for variables containing coordinate data, D for data variables, M for geometry container variables, Do for domain variables, BO for boundary variables, BI for a variable that can be inherited by a boundary variable from a parent, and - for variables with some other purpose.
(I don't think it is necessary to mention here how the BI attributes might (contrary to our recommendations) might be also included explicitly with the boundary variable.)
In Chapter 7, REPLACE: It is recommended not to include a BI attribute on a boundary variable, but it is not forbidden to include a BI attribute provided that it is also present in the parent variable and that it exactly matches the parent variable's attribute, i.e. the data type and value must be exactly the same.
REPLACE:  It is recommended that BI attributes not be included on a boundary variable, but this is not absolutely forbidden.  If a BI attribute is included, it must also be present in the parent variable, and it must exactly match the parent's data type and value.

Dear Karl @taylor13
For the sake of further simplicity:

Each attribute may be used in any of the ways shown in its "Use" entry. G indicates it can appear as a global attribute, and Gr as a group attribute; if use of an attribute is restricted to certain kinds of variables this is indicated as follows: C for variables containing coordinate data, D for data variables, M for geometry container variables, Do for domain variables, BI and BO for boundary variables (see <<cell-boundaries>> for the distinction between BI and BO), and - for variables with some other purpose.

and

It is recommended that BI attributes not be included on a boundary variable , but this is not absolutely forbidden. If a BI attribute is included, it must also be present in the parent variable, and it must exactly match the parent attribute's data type and value.

If it was absolutely forbidden, we would say it MUST NOT be included. I don't think we need to say what isn't the case as well as what is the case. :smile: Moreover, the next sentence implies that it's allowed, otherwise we wouldn't bother to stipulate these conditions.
Best wishes
Jonathan

Dear Jonathan and Karl - thanks for your good suggestions. They are now in the PR: https://github.com/cf-convention/cf-conventions/pull/467/commits/a711f7d0a88474fd46ca21d77f44b0faef14a7f4.


P 18 Separate database for test instances

Currently both test2 and test3 are using the same mongodb database. This is bad practice.
Solution is to clone the test database and save under a separate name.
E0 U6 S7 C5: P18

@Captainkirkdawson . Agreed. Can we have a size estimate?

Implemented


Added scripting example to handle release countries

Summary
This is a…

[ ] Correction
[x] Addition
[ ] Restructuring
[ ] Minor / simple change (like a typo)
[ ] Other

Description of the Change
Document using scripting to modify releasecountry  and handle releases with many release countries.
This is taken from my forum post about this topic in https://community.metabrainz.org/t/handling-of-multiple-release-countries-with-picard-2-3-1/465485

Nonsense, this is already in http://picard-docs.musicbrainz.org/en/tutorials/multiple_release_countries.html :D


[INTERNAL] Azure Pipeline: Use macos13

coverage: 94.653%. remained the same
when pulling 90f41f426a8ce2536a0cd2143c3bd0354f4ae0af on azure-use-macos13
into 58bfa575d24b32d15d29cee3b773f63afbee1d1d on main.


[question]: how override vanilla command.

Is it possible to override minecraft vanilla commands? I just try register command with same arguments and name, but, it work incorrect.

This is not the repository for that. This is for the command dispatcher, called Brigadier. This means that this repository has no connection to Minecraft itself, even if Brigadier is used in Minecraft. If you are using Bukkit, Spigot, Paper, Paperspigot, ForgeServer, etc., please go to their respective support pages and report your issue there.

@PixelLima Yes, sorry, it can be marked as invalid. I want to override them on the Forge API platform.
Issue closed.


How to call the object

I don’t know how to use it when I using leafLet。
in leafLet，an object has been defined，how can i use it with js 0.6.2 like  this:
var EPSG4326  = extend({},Earth,{      code:'EPSG:4326',      projection:LonLat,      transformation:toTransformation(1/180,1,-1/180,0.5) })
EPSG4326  object in L.CRS

I'm not sure how to answer this question.
You might have more luck if you ask in a forum related to leafLet (is that the Dart package or something else?)

I'm not sure how to answer this question.
You might have more luck if you ask in a forum related to leafLet (is that the Dart package or something else?)

i am use flutter to develop web programs with js 0.6.2,but i don't know how to call object in web

Sorry, this issue tracker is meant for filing known issues, not for asking questions. Please consider using a community site like StackOverflow or similar.


v1.1.1 ready?

INSTALL lindel FROM community;

HTTP Error: Failed to download extension "lindel" at URL "http://community-extensions.duckdb.org/v1.1.1/linux_amd64_gcc4/lindel.duckdb_extension.gz" (HTTP 403)

Hi! We will iterate on the community extensions to have them built in the next few hours

Build is done, just checked and it does work now on my side:
INSTALL lindel FROM community;

Works from here too. Thank you very much.


XAMLify ID card computer, Alerts and AME window

About the PR
I also tried AlertControl.cs but I couldn't get it to work.


Handle exit status of error_callback

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Description
If executing external commands is failed and recover in error callbacks, lane should be succeed.
However, user_error! is always called.
This PR make if callbacks return exit code 0, then user_error! is not called. In other words, lane become succeed.
sh "./failure", error_callback: lambda { |result|
  sh "./success"
  next 0
}

If no value is returned from the callback. sh action should be failed. (same as until now.)

I signed it!

Hm... I like what you are trying to do here, but needing to return 0 to make things work feels a little too specific and magical. I don't immediately have a better idea, but let's see what folks think!

Hm, I agreed with your suggestion. However, I have no idea....

I think @ohayon was thinking about a way to approach this...?

I had a thought that because the error_callback is a lambda we could just return sh './success', but I'm not sure if this is the best solution?

Hi everyone, I think we need to think and plan some more about this before we bring in a solution. I'm going to close this for now. 👍