Use hugo Local to make sure events are set to the correct timezone

Another tiny tiny thing: please remove the import statement in the download script and the note in README.md about pytz.

Looks great thank you so much for figuring this out!


Fix image display

In lists, indenting of all paragraphs is required in order to identify images properly (otherwise indent means "display like code")
Before:

After:

fixed the content.


Update storing for auth token

Removed auth token from redux store, save it in memory instead so the user would not have direct access to it.

Closes #609

Your review app has been deployed and is available at 'http://,<IP_ADDRESS>:80'.Learn More about how to test and provide feedback for the app.


Remove JetBrains.IntelliJIDEA.Edu 2022.2.1 to JetBrains.IntelliJIDEA.Educational 2022.2.1

Microsoft Reviewers: Open in CodeFlow

URL: https://download-cdn.jetbrains.com/idea/ideaIE-2022.2.1.exe
Status Code: 200
(Automated message - build 869)


Provide a way to check a request is timed out before executing a blocking task

Some users want to reject to run a blocking task after a request was timed out.
It seems useful to add an option that fails fast when a request was timed out when building a Server
class ServerBuilder {

    public ServerBuilder blockingTaskExecutor(int numThreads, boolean allowExecutingAfterTimeout) {
        if (!allowExecutingAfterTimeout) {
            BlockingTaskExecutor executor =
                    BlockingTaskExecutor.builder()
                                        .numThreads(numThreads)
                                        .taskFunction(task -> {
                                            return () -> {
                                                 ServiceRequestContext ctx = ServiceRequestContext.currentOrNull();
                                                 if (ctx == null || !ctx.isTimedOut()) {
                                                    task.run();
                                                 }
                                            };
                                        })
                                        .build();
        } else {
            ...
        }
    }

}

Let me try it 😄  @ikhoon nim.

Had a chat with @minwoox and he was concerned that a resource could be leaked if a close() method that would be called is not executed in the task job when taskFunction is used.
Alternately, we can wrap a blocking task executor with a decorator.
class TimeoutAwareBlockingTaskExecutor implement BlockingTaskExecutor {
    private final ScheduledExecutorService delegate;

    @Override
    public void execute(Runnable command) {
         ServiceRequestContext ctx = ServiceRequestContext.currentOrNull();
         if (ctx == null || !ctx.isTimedOut()) {
            delegate.execute(command);
         } else {
            throw new RejectedExecutionException("Request has been timed out. ctx: " + ctx);
         }
    }
}

But I wasn't sure that this is a good first issue. Because we need to check overall implementations that use BlockingTaskExecutor in Armeria.
Why don't you pick up another issue? 😅

Aha, I see. Let me take another issue.
Anyway, just curiosity, how your alternative implementation code above can resolve the resource leak issue?

Oh, seems all issues are assigned..? https://github.com/line/armeria/issues?q=is%3Aopen+is%3Aissue+label%3A"good+first+issue"

How about #3683? It could be another good first issue. 😉 Let me update some descriptions in #3683 for the initial direction.

Thanks! Let me take a look.

Could this be rather implemented as a decorator?

That is a good idea! Should it be like this?
class TimeoutLimitingDecorator extends SimpleDecoratingHttpService {

    private final Executor executor;

    public HttpResponse serve(ServiceRequestContext ctx, HttpRequest req) {
        CompletableFuture<HttpResponse> future = ...;
        executor.execute(() -> {
            if (request is not timed out) {
                // delegates to the next service.
            }
        });
        return HttResponse.from(future);
    }
}


V2.5 docs

Describe the change
Updates the API docs for version 2.5. @alexander0042 Just an FYI that I started the changes here. The OpenAPI spec will need to be updated for language parameter. Annoyingly we cannot grab it from DarSky as the documentation is missing languages that are in their translation module.
Type of change

[ ] Updated Home Assistant documentation
[ ] General documentation updates (fixing typos, updating information, etc.)
[ ] Added item to who is using section
[x] Updated docs for new API version release

Checklist

This pull request fixes issue: fixes #152
[x] Update OpenAPI spec
[x] Update API documentation
[ ] Update recent updates section
[ ] Update changelog
[x] Update roadmap
[ ] Update data sources page

@alexander0042 Guess this isn't releasing until next week now? Not a big deal as we can just update the date before this is being merged in.
Do we want to add more information to the icon/summary section to account for the translation module being added?

@alexander0042 I assume you've been busy again this week so I changed the season on the index page to Winter from Fall. Also updated the changelog with relevant fixes from the code repo and set the date to December for now.

Thanks for keeping this fresh! Life got insanely busy for a minute there, but still working on this. I think for now I'm going to push 2.5 out live with just English and French, since I really want to get it live, then add the rest of the translations later.

I've started adding some of the other languages in a python branch in the translations repo https://github.com/Pirate-Weather/translations/tree/python
Hopefully I can get to the rest of them over the weekend if not over the holidays. A bit time consuming converting the functions to python but not too bad. If 2.5 will launch with a subset of the languages then should note somewhere that not all have been added.


Replace volume subgraph query with curve-prices API

https://prices.curve.fi/feeds-docs
Finalize the 0.5.0 release by just replacing the subgraph with curve-prices.
Resolves partially #204 (for mainnet only).

Closed with #277


WIP: Cosmos-simapp example

Overview
In this PR we create an example for cosmos simapp to run locally and on a k8s cluster with 50 validator nodes.

/run_e2e

/run_e2e


Exclusive and a few other common Cake Arguments not supported

Both Cake scripting and Frosting use Spectre.Console and now that Cake.CLI is used that dependency already exists in the project.
This would solve #3 too.
To align with Cake maybe Frosting's settings could be a good starting point
https://github.com/cake-build/cake/blob/b8c287aea1f084be96ffca9d82587e41e8a582da/src/Cake.Frosting/Internal/Commands/DefaultCommandSettings.cs#L13-L54
internal sealed class DefaultCommandSettings : CommandSettings
    {
        [CommandOption("--target|-t <TARGET>")]
        [DefaultValue("Default")]
        [Description("Target task to invoke.")]
        public string Target { get; set; }

        [CommandOption("--working|-w <PATH>")]
        [TypeConverter(typeof(Cli.DirectoryPathConverter))]
        [Description("Sets the working directory")]
        public DirectoryPath WorkingDirectory { get; set; }

        [CommandOption("--verbosity|-v <VERBOSITY>")]
        [Description("Specifies the amount of information to be displayed.\n(Quiet, Minimal, Normal, Verbose, Diagnostic)")]
        [TypeConverter(typeof(VerbosityConverter))]
        [DefaultValue(Verbosity.Normal)]
        public Verbosity Verbosity { get; set; }

        [CommandOption("--description|--descriptions|--showdescription|--showdescriptions")]
        [Description("Shows description for each task.")]
        public bool Description { get; set; }

        [CommandOption("--tree|--showtree")]
        [Description("Shows the task dependency tree.")]
        public bool Tree { get; set; }

        [CommandOption("--dryrun|--noop|--whatif")]
        [Description("Performs a dry run.")]
        public bool DryRun { get; set; }

        [CommandOption("--exclusive|-e")]
        [Description("Executes the target task without any dependencies.")]
        public bool Exclusive { get; set; }

        [CommandOption("--version|--ver")]
        [Description("Displays version information.")]
        public bool Version { get; set; }

        [CommandOption("--info")]
        [Description("Displays additional information about Cake.")]
        public bool Info { get; set; }
    }

Frosting's default command could be used as inspiration on how Spectre.Console parsed commands are passed to Frosting
https://github.com/cake-build/cake/blob/b8c287aea1f084be96ffca9d82587e41e8a582da/src/Cake.Frosting/Internal/Commands/DefaultCommand.cs#L30
And here how it's done in Cake scripting engine
https://github.com/cake-build/cake/blob/a1893a2bba26f49e089d66beeb78421cedf6126d/src/Cake/Infrastructure/ContainerConfigurator.cs#L28

@devlead I believe this is done now.
Can you check?

closing this. let me know if anything is missing


Improving translations using Crowdin

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] UI change (please include screenshot!)
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[X] Internationalization and localization
[ ] Other (please describe):

What is the current behavior?

To add a new language, you need to download this project, duplicate language files, make the translation, test it, create a PR, etc.
When we add new features with new items, we don't know if those items have been translated into other languages.
You need a Visual Studio license (or even worse, editing a RESW file as plain text)

Issue Number: N/A
What is the new behavior?

I've created a public project for this: https://crowdin.com/project/devtoys
This tool allows adding, modifying and removing translations using Crowdin.com without installing Visual Studio and without knowledge of C#, and allow to know if there are new items without translation.

Additionally, now we have a badge with the percentage of translation.

Other information

Note to @veler and @btiteux: currently, I've configured the project with my fork. If this PR is approved we should configure the project with this repository. For that, Crowdin allows integrations through tokens. Additionally, if you have a continuous integration process, you will be able to configure Crowdin to deploy new translations in that process.
I know that this whole process is delicate. So I'm willing to give up the project (renouncing to appear as owner) for the sake of the product.
To add you as project manager, I need a user or an email. Please provide me with one and I will add you to it so you can see the whole flow.
Quality check
Before creating this PR, have you:

[X] Followed the code style guideline as described in CONTRIBUTING.md
[X] Verified that the change work in Release build configuration
[X] Checked all unit tests pass

Related with #415 and #350

Related with #421

Related with #422

Hello,
Thank you for the feature.
I just created an account and joined your project on Crowdin to see how it work.

Hello,
Thank you for the feature.
I just created an account and joined your project on Crowdin to see how it work.

@btiteux now you're administrator.

Thank you.

Hello @veler
sorry for my total absence these two months. My work had me absorbed.
Yes, I want to transfer the ownership of the project to you as I said previously but I can't transfer a project, I have to remove it and you create it (I should have read the Terms and Conditions first 😄).
But that's not a problem. I can transfer the knowledge about the project configuration to you and use my pull request to get the changes in the files.
Let me know when you will be available to delete the project and create it next.
Best regards!

Hello,
Sorry for the late answer. Anytime works for me :)

I've already deleted the Crowdin project, you should create it now. 😉
About the settings:

When you set the branch configuration, you should set a filter like the following:

Source: /src/dev/impl/DevToys/Strings/en-US/*.resw
Translated: /src/dev/impl/DevToys/Strings/%locale%/%original_file_name%

Additionally, in Language Mapping, add the following mapping (to keep the same structure in DevToys repository):

Chinese Simplifed --> zh-Hans
Chinese Traditional --> zh-Hant
I think the rest of the configuration is sufficiently descriptive and needs no special mention. 😉

Thank you so much @abelrodriguez !! :D I follow your guidance and now have a Crowdin project here:
https://crowdin.com/project/devtoys
I still need to update the CONTRIBUTING.md instructions for translation along with getting more familiar with the whole workflow and figure out how external people can contribute to it. But overall, it's great!
I will close this PR. But be sure that we (@btiteux  and I) are very thankful for making us discover this translation tooling and helping us setting it up! 😁


change github perms from repo to public_repo

Coverage remained the same at 75.894% when pulling<PHONE_NUMBER>83d80b7cc62d3f236873f130533255 on change-github-perms into 664c862b9ef9e7d716b45723f574029191a762c5 on master.


⚠ Nano has degraded performance

In e99a043, Nano (https://nano.shuttleapp.rs/up) experienced degraded performance:

HTTP code: 0
Response time: 0 ms

Resolved: Nano performance has improved in 730b989 after 3 hours, 41 minutes.


Fix aggregation link in custom resources page.

Current link is broken.

This change is

@rcorre Please sign the CLA when you get a chance. I can then merge this PR. Thx


Allow airflow-with-dask for python 3.9 and 3.10

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

closes #89

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender


Monster card: Entities not showing up in order they are matched

Example:
- type: custom:monster-card
  card:
    type: entities
  filter:
    include:
      - entity_id: sensor.automations_on
      - entity_id: sensor.automations_all
      - entity_id: automation.*

This will list all automations, followed by sensor.automations_all and sensor.automations_on.
I assume entities are displayed in alphabetical order. In order of matching by include list would be more intuitive and homogenized with how other cards work.

@thomasloven you are correct. I run an entities.sort based on their entity_id. Sorting is tricky with includes and excludes, but if you think of a better system happy to review a PR.


High level NEARlib.js

Describe in high level NEARlib.js + examples how to use it.

https://docs.nearprotocol.com/client-api/js  <-- probably needs gentler intro than just API docs. So I won't close this yet
(Going to need maintenance, but this specific issue is done)

Closing this for different task that not related to autogenerated document.


Auth: Have to log in each time i run the app in editor?

sorry could not fund the bug for this but i read in another bug that this is not supported yet? even tho the readme says auth in editor is supported...
"We don't support auth in the editor at the moment I'm afraid. We don't have a workaround for user authentication in the editor."

Hi,
Firebase Unity does support Auth in the Unity editor for workflow testing only. However, as you've seen, it does not currently persist credentials on disk when testing on desktop.
If persisting credentials on desktop is a workflow that would help you, please add your voice here and describe your use case - this helps our team keep aware of what the community is looking for and prioritize features.
Thanks,
Jon

Persisting credential on desktop is now supported in 6.1.0. Please see release notes here:
https://firebase.google.com/support/release-notes/unity#authentication


[Bug] Create sub task stack failed - "xxxxxxx is not authorized to perform CreateLogGroup with Tags. "

Describe the bug
Create sub task stack failed.
And the CloudFormation Event log shows that: "xxxxxxx is not authorized to perform CreateLogGroup with Tags. "
To Reproduce
Deploy the Data Transfer Hub, and create a s3 transfer task
Expected behavior
Task is created successfully.
Please complete the following information about the solution:

[ ] Version: v2.2.0

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

We found that some accounts may encounter the above problems when starting S3 tasks after newly deploying DTH.
Here is the workaround:

Go to Lambda and search for APICfnWorkflowCreateTaskCfnFn

Click Configuration, Permissions. Click Role Name

Click Add permissions
Click Attach policy. Temporarily Attach an Admin policy.

Recreate the task

We will solve this issue in the next release.

Fixed in V2.3.0


Insert argument wrong order

I write example code
	sql, args, err1 := builder.Dialect(builder.MYSQL).
		Insert(builder.Eq{"issue_id": 1, "username": "vit1251", "body": "Hello"}).Into("comment").
		ToSQL()
	log.Printf("sql = %v", sql)
	log.Printf("args = %v", args)
	log.Printf("err1 = %v", err1)

my output is
sql = INSERT INTO comment (body,issue_id,username) Values (?,?,?)
args = [1 Hello vit1251]
err1 = <nil>

As you can see insert order is changes and as result have wrong mapping on insert.

I use version 0.3.2 via go get and does not on master right now.
P.S. May be create unittest for this issue?

Have added on #42, see https://github.com/go-xorm/builder/blob/master/builder_insert_test.go#L18. Just tagged v0.3.3, please upgrade.


make kubeTest.sh work again

Release note:

NONE

@frankbu: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-suite-rbac-no_auth.sh
53350375a27895783157262a39ac462c6d2ae6ab
link
/test e2e-suite-rbac-no_auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@frankbu: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-suite-rbac-no_auth.sh
53350375a27895783157262a39ac462c6d2ae6ab
link
/test e2e-suite-rbac-no_auth

prow/e2e-suite-no_rbac-no_auth.sh
53350375a27895783157262a39ac462c6d2ae6ab
link
/test e2e-suite-no_rbac-no_auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Force merging since this is for non-functional test scripts used for personal testing.

@frankbu: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-suite-rbac-no_auth.sh
53350375a27895783157262a39ac462c6d2ae6ab
link
/test e2e-suite-rbac-no_auth

prow/e2e-suite-no_rbac-no_auth.sh
53350375a27895783157262a39ac462c6d2ae6ab
link
/test e2e-suite-no_rbac-no_auth

prow/e2e-suite-rbac-auth.sh
b12903dc0ea9be7613e2bdbcf9b734c8d1f6b5da
link
/test e2e-suite-rbac-auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@frankbu: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-suite-no_rbac-no_auth.sh
53350375a27895783157262a39ac462c6d2ae6ab
link
/test e2e-suite-no_rbac-no_auth

prow/e2e-suite-rbac-auth.sh
b12903dc0ea9be7613e2bdbcf9b734c8d1f6b5da
link
/test e2e-suite-rbac-auth

prow/e2e-suite-rbac-no_auth.sh
b12903dc0ea9be7613e2bdbcf9b734c8d1f6b5da
link
/test e2e-suite-rbac-no_auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@frankbu: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-suite-rbac-auth.sh
b12903dc0ea9be7613e2bdbcf9b734c8d1f6b5da
link
/test e2e-suite-rbac-auth

prow/e2e-suite-rbac-no_auth.sh
b12903dc0ea9be7613e2bdbcf9b734c8d1f6b5da
link
/test e2e-suite-rbac-no_auth

prow/e2e-suite-no_rbac-no_auth.sh
b12903dc0ea9be7613e2bdbcf9b734c8d1f6b5da
link
/test e2e-suite-no_rbac-no_auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


only one instance of babel-polyfill is allowed

I want to use your library, but I get this error. how can I handle this?

Uncaught (in promise) Error: only one instance of babel-polyfill is allowed

Really sorry for the delay in my response @mjseyyedi . I've never heard about this error before. Did you manage to solve it?

yes, I did that period of time. but currently I'm not using leaflet anymore


Update the custom colors base map with the tribal data layers and fix the styling / zoom levels of the tribal names

Is your feature request related to a problem? Please describe.
Right now the tribal data is on the tribal basemap. For launch, we need to move it to the custom_colors base map and then make sure it is styled appropriately. We also need to update the visibility zoom level for the tribal data so that it behaves more consistently with the city names and other map labels.
Describe the solution you'd like
Vim to port the data. Kameron to work on styling / zoom levels.
Describe alternatives you've considered
We started down this path on the tribal basemap but stopped when we realized it would most likely be work that needs to be repeated on the other basemap that we plan to use for 1.0.
Additional context
Add any other context or screenshots about the feature request here.
You can see the issue with the tribal names being shown at high zoom in this screenshot -

Here are the styles on the combined Style (custom-colors + updated-tribal-names)
Tribal areas styles
This includes the following data sources:

BIA_TSA
BIA_National_LAR
BIA_Supplemental

Area styles
Color:

value: #758FB3
opacity: 100%

Pattern:

value: none

1px stroke:

value: #1A447F
opacity: 50%

Tribal dots (AK)
This includes Alaska_Native_Villages
Dot styles
Radius:

value: 5px

Color:

value: #1A447F
opacity: 100%

Blur:

value: 0

Opacity:

value: 0.3

Stroke Color:

value: #1A447F
opacity: 100%

Stroke Width:

value: 1px

Stroke Opacity:

value: 1


DropZone component

https://opensource.adobe.com/spectrum-css/dropzone.html
Scoped to accepting drop (no file uploading)

Yo is this in progress?

@SaadBazaz Dropzone is in React Aria as an alpha, and will be in the next release of React Spectrum as an alpha.
https://react-spectrum.adobe.com/react-aria/DropZone.html
#4451
#4757


Move to stream 14 as 10 will go EOL at some point

This should also be synced with changes in nodejs image, so do not merge yet.

[test]

LGTM, lets merge after the tests pass

The failure is not related to this change. The problem is that the conu tests in ruby container depend on pytest but I don't see this dependency specified anywhere.

[test]

The failure is not related to this change. The problem is that the conu tests in ruby container depend on pytest but I don't see this dependency specified anywhere.

Solving this PR in CI.

CI is back and running. Re-testing.
[test]

CI is back and running. Re-testing.
[test]

[test]

[test]

Wau. As old Jenkins CI (OpenShift 3.X) as new Jenkins CI (OpenShift 4.X) are PASSing.
Thanks for the PR! I would say awesome test.

Tests are passing. Merging.


Add shortcuts for various operations

A few other shortcuts are needed :

Cache all Frames (Ctrl + R ?)
Switch version up / down (Ctrl + Page up/down ?)

Parts for the cache all frames (Ctrl + R), recache current frame (Shift + Ctrl + R), and stop buffer (Esc) is done.
The switch version will have to wait, an will be in a separate issue


Add helper support for MMS

MMS is now supported in the API. This is similar to Fax support.

https://developer.ringcentral.com/api-docs/latest/index.html#!#RefCreateSMSMessage

Only documentation has to be updated, the process is 100% the same as for fax: https://github.com/ringcentral/ringcentral-js/blob/master/README.md#fax


parseDate returns wrong date for some locales (ru/fr/...)

Using ParseDate method with some non-english locales returns wrong date.
Steps to reproduce:

Open https://jsfiddle.net/ocme5ubq/2/
Select "Дек 03 2019" (3rd December, 2019) in input
Click "Parse date" button
Result: wrong date Date: Sat Dec 20 2014 00:00:00 GMT+0300
Expected result: Tue Dec 03 2019 00:00:00 GMT+0300

The same is also reproducible if:

to use "locale: { months: { shorthand: [...], longhand: [...] }" directly.
to use 'F d Y' or 'M d Y' formats
some other locales, for example, "fr": https://jsfiddle.net/ocme5ubq/3/
'déc 03 2019' returns '2018' year.

Your Environment

flatpickr version used: 4.6.3
Browser name and version: Chrome 78
OS and version: Windows 10

parseDate uses (\w+) pattern which doesn't work correctly with any non-latin symbols. So every localization that has unicode symbols in month names (like ru/fr/de) gives the wrong default value on initialization or if using parseDate directly.
The solution is to use /([{\p{L}\d]+)/u transpiled to ES5 instead of /(\w+)/.

Hello, I have the same problem here.
parseDate makes the year 2021 => 2018


changed the error messages for Zoe to be more user friendly

The code looks good, but you need to fix the tests before it can be merged (you can test locally by running pytest -x -vv)


Backport "HBASE-27557 [JDK17] Update shade plugin version" to branch-2

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 50s
Docker mode activated.

-0 :warning:
yetus
0m  6s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 40s
branch-2 passed

+1 :green_heart:
compile
0m 46s
branch-2 passed

+1 :green_heart:
shadedjars
4m 10s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 19s
branch-2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 28s
the patch passed

+1 :green_heart:
compile
0m 47s
the patch passed

+1 :green_heart:
javac
0m 47s
the patch passed

+1 :green_heart:
shadedjars
4m 12s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 16s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 28s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
0m 39s
hbase-shaded in the patch passed.

19m 21s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4983/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/4983

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 63ab707c276a 5.4.0-1093-aws #102~18.04.2-Ubuntu SMP Wed Dec 7 00:31:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 29a430ec92

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4983/1/testReport/

Max. process+thread count
427 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-shaded U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4983/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 24s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m  8s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 20s
branch-2 passed

+1 :green_heart:
compile
1m 12s
branch-2 passed

+1 :green_heart:
spotless
0m 55s
branch has no errors when running spotless:check.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 18s
the patch passed

+1 :green_heart:
compile
1m  5s
the patch passed

+1 :green_heart:
javac
1m  5s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  4s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
16m 12s
Patch does not cause any errors with Hadoop 2.10.2 or 3.2.4 3.3.4.

+1 :green_heart:
spotless
0m 52s
patch has no errors when running spotless:check.

_ Other Tests _

+1 :green_heart:
asflicense
0m 19s
The patch does not generate ASF License warnings.

30m 54s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4983/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/4983

Optional Tests
dupname asflicense javac hadoopcheck spotless xml compile

uname
Linux 713d94b133ae 5.4.0-135-generic #152-Ubuntu SMP Wed Nov 23 20:19:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 29a430ec92

Default Java
Eclipse Adoptium-11.0.17+8

Max. process+thread count
78 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-shaded U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4983/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.


fastcgi_finish_request()

After installation I get:
 PHP Fatal error:  Call to undefined function fastcgi_finish_request() in /index.php on line 131, referer: /index.php

Maybe check this function exists on server before executing?

Vadim, what version of php are you using?
@spuds could it be the function is available only if FastCGI is available?

php -v
PHP 5.4.41-0+deb7u1 (cli) (built: May 28 2015 18:22:26)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
apache2 -v
Server version: Apache/2.2.22 (Debian)
Server built:   Dec 27 2014 21:24:33

Yup, looks like its only available if you are running php FPM, ... Thanks for the fix.


Expose outputSum for monitoring and userspace anti-windup

This PR moves the outputSum variable from public to private.
While the same functionality might be provided by a GetIntegral() and SetIntegral(value) or a user-space  myPID.SetMode(myPID.Control::manual);Output=value;myPID.SetMode(myPID.Control::automatic); trick, moving the variable up to Public is a minimal change.
Why I think it is an important change is it helps for understanding the trickiest parts of PIDs: the behavior of the integral term.  Good explanations of the functionality of PIDs often include graphs of the behavior of the components.  Without access to the internal outputSum, it is impossible to see what is going on in the black box.
I've been experimenting with simulating a 1-D heat transfer problem controlled by a PID:
https://wokwi.com/projects/359818835102393345

Note that it shows the exposed integral on the LCD and the time-series, which I think is very helpful for understanding the interactions of the tuning parameters.

Thanks.  I updated the simulator at https://wokwi.com/projects/359818835102393345
to use your current version unmodified.
The current version doesn't seem to have migrated into the Arduino Library system yet, but should soon.

Oh, I only pushed the updates ... I'll create a new version shortly (QuickPID 3.1.5) and tag so Arduino can migrate it.


fix(v2): fix svg loader

Motivation
Fix issue https://github.com/facebook/docusaurus/issues/3179
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
By adding dogfood

LGTM thanks, just updated a bit the doc to make it reliable regarding versioning as relative path to statics may break

LGTM thanks, just updated a bit the doc to make it reliable regarding versioning as relative path to statics may break

ok


[Network] CMake Base Include Sweep Misses Source Files

This issue directly refers to the file AsyncTask.cpp not being included into CMake builds. This is because only headers are included in the initial include sweep. Add another search component to the base sweep to include *.cpp files as well.

This has been fixed with commit 84b3cbca6ab8e88002c986297846d006c101f03d


could not get it to work, here's my errors:

Traceback (most recent call last):
File "chatbot.py", line 254, in
main()
File "chatbot.py", line 249, in main
train()
File "chatbot.py", line 127, in train
test_buckets, data_buckets, train_buckets_scale = _get_buckets()
File "chatbot.py", line 85, in _get_buckets
test_buckets = data.load_data('test_ids.enc', 'test_ids.dec')
File "C:\Users\Olga\Anaconda3\envs\tensorflowbot\data.py", line 193, in load_data
encode_file = open(os.path.join(config.PROCESSED_PATH, enc_filename), 'r')
FileNotFoundError: [Errno 2] No such file or directory: 'processed\test_ids.enc'

run python data.py first


Memory leak

I am trying to use 'vt decompose' to decompose variants from a large VCF file (~80G compressed). When I use the '-s' option, the RAM usage grows to very high levels. It appears to roughly track the size of the uncompressed input file read to that point. I don't see the problem running 'vt decompose' without the -s option. I have started trying to track down the source, but haven't found it yet.
Your help would be much appreciated. Thanks.
-Jason

Is there anyway you can link me to your file?

Not these specific VCF files. I'd think you should be able to reproduce the effect with any big VCF file though. Maybe something from 1000 Genomes phase 3? The key clue, I think, is the fact that the same file processed without the -s flag uses a constant low level of RAM.
-Jason

can you try the updated version?

So far so good. Memory usage is low and steady, no errors yet. Thanks for the quick fix!
-Jason

Let me know if there is still an issue, the implementation is not good, I'm just patching it.  Will recode it properly eventually.


Show private event in a simple way on the calendar

If there are several private events, give the admin user a way to see which events are private.

Working!


CSP-410 - Validation Middleware, and controller updates

FluentValidation middleware added to ServicesRegistration, and controller styling update to ROATP standards

PR closed due to changes merged with : https://github.com/SkillsFundingAgency/das-aan-hub-api/pull/23


Problem_Statement_14

Given a linked list of N nodes. The task is to check if the linked list has a loop. A linked list can contain a self-loop.
Example 1:
Input:
N = 3
value[] = {1,3,4}
x = 2
Output: True
Explanation: In above test case N = 3.
The linked list with nodes N = 3 is
given. Then value of x=2 is given which
means last node is connected with xth
node of linked list. Therefore, there
exists a loop.

Hey! Will you please assign me this issue?

I am Nutan Tupe From CCEW Pune. I would like to work on this issue

I am Samruddhi Nabriya from CCEW, Pune.

Hi, I would like to work on this issue. Please assign it to me.
Sanyukta Muley
CCOEW Pune

Yes. You can start working on it @samruddhi-10

I would like to work on this issue.
Srushti Sulgudle


Processing of initial, final balances, remaining tokens #58 #62 #82

https://github.com/spearbit-audits/LiFi/issues/82#issuecomment-1261660648


Compitable with yolov7- tiny or yolov4-tiny ?

Hello guys,
first of all i want to thank you for this great Tutorial.
I have a question i want to ask.
Can i use yolov7-tiny or yolov4-tiny instead of yolov3?
If yes, what changes do I need to make?
I am fairly new to this and would really appreciate your help. Thanks.

Module 3 - Develop and deploy Custom Object Detection Models with IoT Edge DeepStream SDK Module covers most of what is required in order to support custom YOLO implementations.  You should be able to extrapolite what is likely required from this area of the documentation.  Let us know if you have success!


chore(labeler): fix PR labeler

Description

This fix the following 'Error: YAMLException: unidentified alias ".md"' following https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pull/845
@akoserwal can I get your review again?
Verification Steps

Code review is enough
Checklist (Definition of Done)

[ ] All acceptance criteria specified in JIRA have been completed
[ ] Unit and integration tests added that prove the fix is effective or the feature works (tested against emulated and non-emulated OCM environment)
[ ] Documentation added for the feature
[ ] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] Required metrics/dashboards/alerts have been added (or PR created).
[ ] Required Standard Operating Procedure (SOP) is added.
[ ] JIRA has created for changes required on the client side

Ignore the failing CI for PR labeling, it is failing for something that should be fixed in this PR. The change needs to get in for CI to start passing again.


When building the environment, the time to build ui is too long

In GitLab by @cuiaq123 on Nov 8, 2017, 09:44
If you are reporting a problem, please make sure the following information are provided:

Version of board (last git commit number) , docker engine and docker-compose.
Config files of board, you can get them by packaging "board.cfg" and files in the same directory, including subdirectory.
Log files, you can get them by package the /var/log/board/.
Other necessery information.

In GitLab by @sokril on Nov 8, 2019, 08:14
closed

In GitLab by @sokril on Nov 8, 2019, 08:14
assigned to @wknet123


Refactor git config

Your checklist for this pull request
🚨Please review the guidelines for contributing to this repository.

[x] Ensure all commits include DCO sign-off.
[x] Ensure that your contributions pass unit testing.
[x] Ensure that your contributions contain documentation if applicable.

Description
The Git module has config and global_config methods that are available only when Git module is included. Refactored the code to remove duplication and to make it more explicit we are managing git config not the library setup.

tests are passing, the code is rebased, anything else I should do?

still waiting for the review

still waiting for the review

still waiting for the review

still waiting for the review

I am closing this PR to have a broader discussion about how git config should work in this gem in the next major release in #656.


Issue109 sorting testcases

Multidata tests and normal tests now come in the right order.
.ipf file for quick tests is attached:
issue109-sorting-testcases.zip
I have the feeling that in sortTestCaseList the second for-loop could be solved in a 1-liner, but have no idea how.
Edit: closes #109

Change AddListItem in getTestCasesMatch, CheckFunctionSignaturesTC to not change order with AddListItem(item, list, ";", inf)

I know I am not assigned yet, but how about:
		lineNumberWave[] = str2num(StringByKey("PROCLINE", FunctionInfo(testCaseWave[p], procWin)))
to change the for loop to auto indexing. Maybe even MultiThread can be applied.

I know I am not assigned yet, but how about:
 lineNumberWave[] = str2num(StringByKey("PROCLINE", FunctionInfo(testCaseWave[p], procWin)))
to change the for loop to auto indexing. Maybe even MultiThread can be applied.

Sure, nice idea. Will be updated with the next push.

Your requests are fulfilled, furthermore a small description was added at docu/sphinx/source/basic.rst about the now fixed order of the test cases.

Please also add the issue109 example from your first comment in internal_dev folder as testcase_order.

 The content of the commit message to the changes from GetTestCaseList to RunTest was changed.

@MathiasAugstein ok I have removed the string functionInfoString line as functionInfoString is not used.


pod_to_html helper now will remove spaces at the start of the line for code blocks

For now Mojolicious removes this spaces only when it renders /perldoc. Will be good if pod_to_html helper will also remove this useless whitespaces.
See also https://rt.cpan.org/Public/Bug/Display.html?id=103389

Thanks, applied.

This has broken the ASCII art in the Growing Guide


openapi-react-query select option does not infer types correctly

Description
The select property of the query options does not infer the type correctly.
Reproduction
Simply return a different type from the select call.
Example:
const { data: firstUser } = QAPI.useQuery(
    "get",
    "/api/users", // endpoint usually returns an array of users, e.g. User[]
    {},
    {
      select: (data) => data[0], // want to return something different here, i.e. User
    },
  );

In this case you get an error from the compiler stating Type User is not assignable to type User[] ...
Expected result
Type inference just works.
Checklist

[ ] I’m willing to open a PR (see CONTRIBUTING.md)

Closing as duplicate of #1845


(WIP) Improve buffer management

[ ] Create separate BufferPool class (extract code from Project class)
[ ] Write specs for BufferBool class
[ ] Explore using IndexedDB for storing unsaved buffers
[ ] Profile changes

Hey @kuychaco, this PR has been open for a while now. Are there any plans to continue working on the buffer management improvements? If not is it okay if I close this?

Thank you for your issue!
We haven't gotten a response to our questions in our comment above. I'm going to close this but don't hesitate to reach out if you have or find time to resolve the conflicts, we'll be happy to reopen the PR.


KIC 2.0 crashes if udpingress controller disabled and udpingress CRD not present

Reproduction steps:

git checkout bug/udpingress-issue-1498
kubectl apply -k ./deploy/manifests/base - note that CONTROLLER_CONTROLLER_UDPINGRESS=false is set and the UDPIngress CRD is not deployed in this case
observe that Railgun produces the following logs before crashing:Error: failed to wait for udpingress caches to sync: no matches for kind "UDPIngress" in version "configuration.konghq.com/v1beta1"
time="2021-07-07T13:29:24Z" level=error msg="error received after stop sequence was engaged" error="context canceled" logger=controller-runtime.manager

Desired behavior: KIC 2.0 not crashing when the UDPIngress CRD is not present in the cluster and CONTROLLER_CONTROLLER_UDPINGRESS=false
Actual behavior: KIC 2.0 crashes in the scenario above

CONTROLLER_CONTROLLER_UDPINGRESS=disabled ? Compare to https://github.com/Kong/kubernetes-ingress-controller/blob/23d90f3e3522033d4e26eb1dda418a30ba016414/railgun/test/integration/suite_test.go#L238-L246
These are strings because we have 3 statuses, and this is a possible point of user confusion (hence why we have this issue)
Do we want to convert them to booleans? To my point earlier in the second half of https://github.com/Kong/kubernetes-ingress-controller/pull/1479#issuecomment-872593637, we don't currently use auto and it's not clear if we have a good reason to distinguish it from enabled.

CONTROLLER_CONTROLLER_UDPINGRESS=disabled ? Compare to
https://github.com/Kong/kubernetes-ingress-controller/blob/23d90f3e3522033d4e26eb1dda418a30ba016414/railgun/test/integration/suite_test.go#L238-L246
These are strings because we have 3 statuses, and this is a possible point of user confusion (hence why we have this issue)
Do we want to convert them to booleans? To my point earlier in the second half of #1479 (comment), we don't currently use auto and it's not clear if we have a good reason to distinguish it from enabled.

I'm in favor of converting these to boolean flags based on current usage, however I don't think this is the scope for that.

First glance, the branch that encountered this error doesn't account for UDPIngress in the custom_types.yaml, which ultimately triggers this problem. Not to say we can't work around it some other way, but suffice to say TCPIngress is being treated differently.

@mflendrich I guess I'm confused. I'm unable to reproduce this problem using the commands you provided, so I tried another route:
$ cd railgun/
$ make test.integration.cluster
$ export KONG_PROXY_URL="http://$(kubectl -n kong-system get svc ingress-controller-kong-admin -o=go-template='{{range .status.loadBalancer.ingress}}{{.ip}}{{end}}'):8001"
$ go run main.go manager --kong-admin-url ${KONG_PROXY_URL} \
        --kubeconfig /home/shane/.kube/config \
        --watch-namespace default \
        --controller-kongstate=enabled \
        --controller-ingress-networkingv1=enabled \
        --controller-ingress-networkingv1beta1=disabled \
        --controller-ingress-extensionsv1beta1=disabled \
        --controller-udpingress=disabled \
        --controller-tcpingress=disabled \
        --controller-kongingress=disabled \
        --controller-kongclusterplugin=disabled \
        --controller-kongplugin=disabled \
        --controller-kongconsumer=disabled \
        --controller-knativeingress=disabled

In this setup I use a fresh cluster, don't deploy ANY CRDs (including the UDPIngress CRD), and start the controller with the controller intentionally disabled.
When I do this there are no failures in the deployment.
Also can you help me understand where CONTROLLER_CONTROLLER_UDPINGRESS is supposed to be coming from and/or utilized?

CONTROLLER_CONTROLLER_UDPINGRESS is equivalent to --controller-udpingress. We automatically map the cobra flags to CONTROLLER_WHATEVER at:
https://github.com/Kong/kubernetes-ingress-controller/blob/129c516b7a7dabb7bf974034db713ac6555e1774/railgun/cmd/rootcmd/env.go#L12-L28
Most of our manifests use environment variables over the flag versions.

CONTROLLER_CONTROLLER_UDPINGRESS is equivalent to --controller-udpingress. We automatically map the cobra flags to CONTROLLER_WHATEVER at:
https://github.com/Kong/kubernetes-ingress-controller/blob/129c516b7a7dabb7bf974034db713ac6555e1774/railgun/cmd/rootcmd/env.go#L12-L28
Most of our manifests use environment variables over the flag versions.

Roger that thank you. But I'm still stuck without being able to reproduce this, and it seems even more true that my repro should have worked... :thinking:

I misunderstood the problem! the problem is actually that the ENV var accepts bool and that somehow results in the error, my bad I must have just misread. That said, I don't see how this is a high severity issue so let's change that. I'll get this fixed.

Looks like this has nothing to do with UDPIngress at all, a potential fix is now up for review in #1511 and I'm going to update the issue to better reflect my findings.

Thanks Travis and Shane for investigating this - seems that there's a bug but a different one that I thought, and uncovered by me providing an invalid input to a mechanism that I wrote myself :man_facepalming:.


Output batching with sparse child array mapping

Hello! I'm seeking some guidance on output batching for my specific use case, having a little difficulty figuring out how to get output batching working as I would like (config example below). Using a kafka input, essentially each input message has a Children array that can contain 0-N elements, and this is generally quite sparse in distribution. On the high end this array contains ~200 elements, for many messages it contains only a few, and for at least 50% it is an empty collection.
The topic being consumed has 30 partitions, and this pipeline has 5 brokered input copies running across 6 replicas (so each input copy has a single partition).
input:
  broker:
    copies: 5
    inputs:
      - kafka:
          addresses:
            - ${KAFKA_BROKERS}
          consumer_group: ${CONSUMER_GROUP}
          topics:
            - ${KAFKA_TOPIC}
          batching:
            period: 100ms
            count: 5

pipeline:
  processors:
    - bloblang: |
        root = this.Children.map_each(
          x -> {
            "ID": x.Id,
            "Link": x.Url
          })
    - unarchive:
        format: json_array

output:
  broker:
    copies: 10
    pattern: greedy
    outputs:
      - aws_dynamodb:
          backoff:
            initial_interval: 1s
            max_interval: 30s
          max_retries: 5
          max_in_flight: 3
          table: "<table_name>"
          json_map_columns:
            "": .

I can get this working if I define batching on the input (as seen above), but then this results in very spiky output batches (ie. up to ~200 items in batch writes) which slows down throughput massively (I assume the dynamo output hits the 25 max batch write limit, and writes the items one-by-one).
If I define batching on the output, processing stalls completely, since I assume the input is waiting to commit the offset for a batch that will never be flushed in the case of the processor not generating any messages (ie. all messages in the input batch have an empty Children array).
What I really want is to be able to limit the output batch to 25 items (falls within Dynamo batch write limit) somehow accounting for the fact that input items are not guaranteed to produce any messages. Is there a way to achieve this? I assume I'm missing something critical in the way I define the input, but I'm kinda stuck right now.
Any guidance is much appreciated!

I think I may have solved at least part of this with the split processor ... is there anything else I can do at the input level to improve throughput?

Hey @Archanian, there's a few things that might help.
If you're using a relatively up to date version of benthos you don't need brokers on either end, the input will automatically saturate processing threads and outputs, and I believe the output should perform just as well by removing the broker and increasing the field max_in_flight.
The next thing that'll help is that you can make the batching simpler now by setting the kafka field checkpoint_limit. This field controls how many messages of the same partition can be processed asynchronously (out of order), and allows messages to flow through to the output level without the awkward lockstep that forces you to batch at the input level.
If you set that to something liberal like 100 then you'll be able to batch messages at the output level and even out the flow, as the batching will be satisfied both by slow traffic of messages with lots of items and also high traffic of messages with fewer items.
Finally, this is a preference thing but I would perform the unarchive bit at the input level and end it with a split so that the batches are fully broken down before the processing pipelines. You don't have any other processing right now but if you were to add some in the future then this would help vertically scale the messages across processing threads.
With all that stuff together I think this config might be a good place to start:
input:
  kafka:
    addresses:
      - ${KAFKA_BROKERS}
    consumer_group: ${CONSUMER_GROUP}
    topics:
      - ${KAFKA_TOPIC}
    checkpoint_limit: 100
  processors:
    - bloblang: |
        root = this.Children.map_each(
          x -> {
            "ID": x.Id,
            "Link": x.Url
          })
    - unarchive:
        format: json_array
    - split: {}

output:
  aws_dynamodb:
    backoff:
      initial_interval: 1s
      max_interval: 30s
      max_retries: 5
    max_in_flight: 30
    table: "<table_name>"
    json_map_columns:
      "": .
    batching:
      period: 500ms
      count: 20

Let me know if that seems to work better. In the next major version release I'm going to be re-evaluating the default values we have for things like max_in_flight and checkpoint_limit, so I'm quite interested in feedback.

Hey @Jeffail thanks for the prompt and detailed response, I really appreciate it. One question I have about increasing checkpoint_limit to 100 - would this still result in stalling if there were no children elements in a 100 message span? Would the limit need to be such that there is a guarantee of at least one message? If so, that presents a problem, since the theoretical limit is infinite.
Good to know about the brokers, I'll test that out and see what the throughput difference is. We're also running these pipes in ECS containers, so the CPU scheduling is a little less reliable. You raise a good point about scaling processors, I'll move the existing ones to the input.
With the original config I posted, plus a split processor to ensure batches are limited to 25, I have been able to achieve ~60k writes/sec to Dynamo, which I think is pretty good? It could probably go even faster with bigger containers, CPU was close to saturated.

No problem @Archanian! You won't get any issues with stalling. One thing that might be worth also doing if the number of children might be zero is delete the messages from the bloblang mapping with an assert like this:
        root = this.Children.map_each(
          x -> {
            "ID": x.Id,
            "Link": x.Url
          }).not_empty().catch(deleted())

OK so something is not right here ... I have made the changes you recommended - removed brokers, added checkpoint_limit of 100 to the input, and adding batching to the output, ie:
output:
  aws_dynamodb:
    batching:
      period: 200ms
      count: 25
    backoff:
      initial_interval: 1s
      max_interval: 30s
    max_retries: 5
    max_in_flight: 30
    table: "<table_name>"
    json_map_columns:
      "": .

This prevents stalling, however it appears batching is not working correctly, I'm seeing batches wayyyy over 25 (and as a result, terrible throughput). Adding a split processor with a size of 25 has the effect of partially limiting batches, but not all them, its really quite strange ...

As you can see, a lot of batches are capped at 25, but a bunch of them aren't. It doesn't make any sense.
As a side note, it would be great if the dynamo writer would internally cap batch write operations at 25 items.

@Jeffail as another side note, I didn't mention this earlier but we are specifying a thread count (20) on the pipeline which results in much greater throughput. Moving the processor to the input means we don't have this control, and throughput is much lower a result.

@Archanian yeah that's odd, can you share the whole config? I'll try and reproduce it locally.

Sure thing:
input:
  kafka:
    addresses:
      - ${KAFKA_BROKERS}
    checkpoint_limit: 100
    consumer_group: ${CONSUMER_GROUP}
    topics:
      - ${KAFKA_TOPIC}

pipeline:
  threads: 20
  processors:
    - bloblang: |
        root = this.Children.map_each(
          l -> {
            "ID": l.Id
            "Link": l.Url,
          }).flatten()
    - unarchive:
        format: json_array
    - split:
        size: 25

output:
  aws_dynamodb:
    batching:
      period: 200ms
      count: 25
    backoff:
      initial_interval: 1s
      max_interval: 30s
    max_retries: 5
    max_in_flight: 30
    region: us-east-2
    table: "<table_name>"
    json_map_columns:
      "": .

Remove the split processor for truly wild batch sizes :D

Ah okay, does everything look good when you run with:
input:
  kafka:
    addresses:
      - ${KAFKA_BROKERS}
    checkpoint_limit: 100
    consumer_group: ${CONSUMER_GROUP}
    topics:
      - ${KAFKA_TOPIC}

pipeline:
  threads: 20
  processors:
    - bloblang: |
        root = this.Children.map_each(
          l -> {
            "ID": l.Id
            "Link": l.Url,
          }).flatten()
    - unarchive:
        format: json_array
    - split:
        size: 1

output:
  aws_dynamodb:
    batching:
      period: 200ms
      count: 25
    backoff:
      initial_interval: 1s
      max_interval: 30s
    max_retries: 5
    max_in_flight: 30
    region: us-east-2
    table: "<table_name>"
    json_map_columns:
      "": .

That's done the trick, batch sizes look correct now. So the split of 1 is required in the processor pipeline?

Yeah so the reason for that is that batching mechanisms are inclusive of the batch that triggered it, so if you have the config:
    batching:
      count: 25

And then feed it a batch of 2 messages, then followed by a batch of 30 messages, you'll end up with a flushed batch of 32 messages. This behaviour is intentional as we consider batches to be sacred and so we keep them together unless your configuration instructs otherwise, that's why you need to split the batch resulting from unarchive explicitly.
There's definitely room for reconsidering this as the default, where we could add an opt-in configuration to batching mechanisms that preserves the input batches, but we'd need to wait for v4 before we can implement it as it'd be a breaking change.
However, I can definitely add some debug logs to the batching mechanism so that it's clearer how and why these batches are being formed the way that they are. I'm going to mark this as a documentation issue to get that bit done, but if you have further questions then feel free to continue the convo in here.

Gotcha, thanks for the explanation!
What are your thoughts on making the dynamo writer internally limit bulk writes to 25 items? So it would split any batches larger than this making it invisible to the end user.
This has a huge impact on throughput from my tests, it might be worth considering?

Yeah good point, definitely something we should be forcing at the lower level, can you open a separate issue for that?

Absolutely, linked here.


Feature Request: Support pixi virtual environments

Like the title says, pixi is another great package manager for python currently gaining steam. Would love to be able select venv's created through it

If you try the new regexp branch of the plugin, odds are that they will just be found automatically. If they are in some special location, you can add your own search also. :) See the Readme at the top for links to regexp version.

The new branch did work! Thanks.


ci: fix macos workflow

:tada: This PR is included in version 2.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


New utility functions

added pisScriptAddress, pfindEffectInput, and
pfindEffectAddress. These functions are commonly used by effects, like in #46 and #49.

You may want to check this commit out: https://github.com/Liqwid-Labs/agora/commit/139f9f933a821a8d98b003c0a3a1f0e19eac9611
I made a bunch of change today, which might be more generic.

Ahh how did I missed that, I'll update it

@chfanghr committed the functions you mentioned, sorry it took long (because I was as school)...

Don't worry; pls prioritize your school stuff if needed😄.

@chfanghr I removed findEffectInput which was in fact doing same thing as pfindTxInByTxOutRef, fixed some comments, and reimplemented findTxOutByTxOutRef

Finally, it looks good to be merged! 🎉


propose HIPE: trust ping protocol

Signed-off-by: Daniel Hardman<EMAIL_ADDRESS>Describe how agents could ping one another to prove connectivity and security.

I think the protocol needs at least an optional nonce.  I think it should be required but those with better crypto chops could convince me that the overhead is not needed sometimes.
Cryptographic Nonce

I'm confused, if the @id is not required for the ping but the @thread is required for the pong and the @thread really requires an thid that is based on the @id of the ping. How could this logically work without an @id?


Port basic DistinguishedNameParserTest from AOSP

Port the test from http://r.android.com/183814 . This consists of two commits:
(1.) minimal changes to make the test compile and runnable, (2.) update
expectations to current behavior to make the test pass.
DistinguishedNameParser is an internal API, so this test is mostly to ensure
that any future behavior changes are deliberate.

Neat.


CTRL+D replaces the search pattern

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.70.0
OS Version: Windows_NT x64 10.0.19044

Steps to Reproduce:

Select any word
CTRL+D
The selection has replaced my current search pattern (from CTRL+F or CTRL+H)

This didn't used to happen and should not happen. If I want to change my current search pattern, I'll change it. This is especially annoying mid-refactoring after building a non-trivial regex, and using CTRL+D to make adjustments afterwards. Which erases the pattern.

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.72.0. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!


PlanDefinition $apply supports reporting warnings/errors

As a DTR user, I want to see any warnings/errors that occur in the $apply process to see any issues with CQL or execution.
The DTR spec requires reporting CQL syntax and execution errors to the user, but these do not block returning the Questionnaire.
https://build.fhir.org/ig/HL7/davinci-dtr/specification__behaviors__execution_of_CQL.html#engine-execution
NOTE: The non-fatal CQL error applies only to $prepopulating/$populating Questionnaires. PlanDefinitions can also reference CQL directly for workflow purposes. That would be a fatal error since the workflow would be broken.
The Measure evaluation and CQL compiler have a pattern where an error aggregator is passed as part of the context. The aggregator is used to collect the various errors, codes, and severities. After the evaluation / compilation is complete, the errors are used to generate an OperationOutcome with a set of issues.
The DSTU3/R4/R5 processors would all need to be updated.
Acceptance Criteria:

PD $apply has been updated to include an OperationOutcome in the CarePlan/RequestOrchestration in the output
The OperationOutcome includes any warnings for errors that occurred and were non-fatal
CQL syntax errors in particular are reported with the MSG_BAD_SYNTAX code
Tests exist for success, fatal error, non-fatal syntax error, and non-fatal execution error.

Need to follow-up with Bryn on this.

Closed by #249


endpoint to get the SystemKey corrected

fixes #16189

@mariumfirdous : Thanks for your contribution! The author, @ggailey777, has been notified to review your proposed change.

Closing based on review comments from @olandese


Restructuring of Grafana

What changed, and why it matters
As part of the efforts to achieve a consistent structure, appearance, and tone across all service documentation, the Grafana topics have been restructured to match those of Flink.

also fixes #1490


JavaScript: Rename hasPathFlow to hasFlowPath for consistency with other languages.

I have no idea why the names were inconsistent to begin with, probably just an oversight on my part.

(Thanks to @adityasharad for pointing this out.)


a ios app product page

.

Preview UI
Based on the provided code snippet, I will create a high-fidelity working prototype for an iOS app product page. The page will include a header, product details, screenshots, and a download button. Here is the Vue code for the iOS app product page:
This Vue code provides a structured layout for an iOS app product page, including the app name, category, version, screenshots, description, download button, and additional information with tabs for details and reviews. Feel free to customize it further based on your specific requirements.

Preview UI
Based on the provided wireframe and requirements for an iOS app product page, I have created a high-fidelity working prototype using Vue. The prototype includes a header with a back button, product image, product details, and a button to add the product to the cart.
Here is the Vue code for the iOS app product page:
In this prototype, I have included a header with a back button and a cart button. The product image, product name, description, price, and an "Add to Cart" button are also included. The design follows iOS app design patterns and uses Tailwind CSS for styling.


Negative test for humanStandardTokenFactory

Separate issue identified from #16
To consider, how would an attacker try to exploit the factory...

I haven't found any issue with it fwiw.
It uses Contract external calls, so it will rethrow if there's an exception. Code can re-enter, but it is pointless as they will just be creating new token contracts where they are the issuer.
createdByMe can be increased ad inifitum, but there's no gas limit attack possible.

I'm going to mark everything but createHumanStandardToken as constant. It should be pretty clear then that there's no attack.


Azure Point-in-time restore fails with no description

When attempting a Point-in-time restore it fails with a generic message with no details as to why it may have failed.
"Restoring SQL database failed in resource group YOUR_RESOURCE_GROUP_NAME."

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: de79f464-39dc-a5ad-0d9d-fab2ed248222
Version Independent ID: 6cf17fc7-3bdd-c419-8d9d-7d3067bb86ae
Content: Restore an Azure SQL database from a backup
Content Source: articles/sql-database/sql-database-recovery-using-backups.md
Service: sql-database
Product: unspecified
GitHub Login: @anosov1960
Microsoft Alias: sashan

@aaronralls Thanks for the feedback. We are actively investigating but, we did want to ask if you currently hold an active Azure support plan?

Yes my company, Goodyear, has a support plan.

I have two questions:
1.) Should this documentation discuss why failures commonly occur?
2.) Should the Azure Portal Interface be improved to clearly state why a restore fails?

@aaronralls Completely agree. So, the initial step is to have the issue investigated. Once root cause is identified, please update this with a support summary. The documentation could use an update with regard to most common errors.
Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.
Regards,
Mike

@aaronralls Thanks for the feedback. It’s likely that restore failed with some internal error and we return a generic error in that case. Has it been investigated by support? if so can you pls share the ticket nr. If not I encourage you to report asap if you see this again.


Permission Issue When Trying To Train

Hello,
When attempting to train using
python -m frame_interpolation.training.train --gin_config frame_interpolation/training/config/film_net-L1.gin --base_folder frame_interpolation/trainingtest --label run1
I receive the following error:
tensorflow.python.framework.errors_impl.PermissionDeniedError: Error executing an HTTP request: HTTP response code 403 with body 'SecurityPolicyViolatedRequest violates VPC Service Controls.Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: aLtoSx_oFl9dWx4WZCyDyUQ43UmTHYSvKLHLUf-2yKXOQMQ-cRAzkg'
when reading gs://xcloud-shared/fitsumreda/frame_interpolation/datasets/vimeo_interp_train.tfrecord-00003-of-00200
[[{{node MultiDeviceIteratorGetNextFromShard}}]]
[[RemoteCall]] [Op:IteratorGetNext]
My guess is that it is related to a permission setting, but I am unsure and do not know a solution how to fix from my side.
https://cloud.google.com/vpc-service-controls/docs/troubleshooting

Hey, thanks for your interest in our work.
Are you running it from a local machine or on a VM sitting in a cloud or
farm?
I’d try to append ‘—cpu’ and test the training loop on a local machine. It
might help clarifying the error messages.
On Tue, Oct 11, 2022 at 13:38 jigglejiggle @.***> wrote:

Hello,
When attempting to train using
python -m frame_interpolation.training.train --gin_config
frame_interpolation/training/config/film_net-L1.gin --base_folder
frame_interpolation/trainingtest --label run1
I receive the following error:
tensorflow.python.framework.errors_impl.PermissionDeniedError: Error
executing an HTTP request: HTTP response code 403 with body '
SecurityPolicyViolatedRequest violates VPC Service Controls.
Request is prohibited by organization's policy.
vpcServiceControlsUniqueIdentifier:
aLtoSx_oFl9dWx4WZCyDyUQ43UmTHYSvKLHLUf-2yKXOQMQ-cRAzkg'
when reading
gs://xcloud-shared/fitsumreda/frame_interpolation/datasets/vimeo_interp_train.tfrecord-00003-of-00200
[[{{node MultiDeviceIteratorGetNextFromShard}}]]
[[RemoteCall]] [Op:IteratorGetNext]
My guess is that it is related to a permission setting, but I am unsure
and do not know a solution how to fix from my side.
https://cloud.google.com/vpc-service-controls/docs/troubleshooting
—
Reply to this email directly, view it on GitHub
https://github.com/google-research/frame-interpolation/issues/64, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADVE3UOWIDCJVV4T7DSGGNTWCXF27ANCNFSM6AAAAAARCUXO3I
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Thank you for the reply.
I'm running on a local machine with normal interpolation working.
Ultimately, I'm trying to use the aux flag for additional outputs. It appears to only be accessible during training (which is why I'm trying to train), but maybe there is a different way to enable it ?
Per your recommendation, I tried adding the CPU flag:
python -m frame_interpolation.training.train --gin_config frame_interpolation/training/config/film_net-L1.gin --base_folder frame_interpolation/mytraining --label run1 --mode cpu
But still received the same error unfortunately.  It appears to be regarding the downloading of the vimeo dataset and not having permission ?
File "C:\ProgramData\Anaconda3\envs\frame_interpolation\lib\site-packages\tensorflow\python\ops\gen_dataset_ops.py", line 2727, in iterator_get_next
_ops.raise_from_not_ok_status(e, name)
File "C:\ProgramData\Anaconda3\envs\frame_interpolation\lib\site-packages\tensorflow\python\framework\ops.py", line 6941, in raise_from_not_ok_status
six.raise_from(core._status_to_exception(e.code, message), None)
File "", line 3, in raise_from
tensorflow.python.framework.errors_impl.PermissionDeniedError: Error executing an HTTP request: HTTP response code 403 with body 'SecurityPolicyViolatedRequest violates VPC Service Controls.Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: 9tZCPPdmrCG_8xKNNCAxLMW_J9nRZIuV1mG-qStudaQdOOXQ2ZtZuw'
when reading gs://xcloud-shared/fitsumreda/frame_interpolation/datasets/vimeo_interp_train.tfrecord-00006-of-00200
[[{{node MultiDeviceIteratorGetNextFromShard}}]]
[[RemoteCall]] [Op:IteratorGetNext]

Your config file is still pointing to the training data that is not publicly accessible. You need to change gs://xcloud-shared/fitsumreda/frame_interpolation/datasets/vimeo_interp_train.tfrecord-00006-of-00200 to your own copy of Vimeo-90k TFRecords. There are instructions how to construct the dataset by yourself.
I'll close this issue, feel free to create an issue if you run into anything

Thank you for your help. I got it training now.  It threw this warning, but I will assume that that's normal.
UserWarning: Input dict contained keys ['y', 'path'] which did not match any model input. They will be ignored by the model.

The warning is normal. It means the model graph doesn’t use the target
image ‘y’ and the image’s filepath string ‘path’. The target ‘y’ is usef in
the loss functions which isn’t part of the model graph.
On Mon, Oct 17, 2022 at 10:54 jigglejiggle @.***> wrote:

Thank you for your help. I got it training now. It threw this warning, but
I will assume that that's normal.
UserWarning: Input dict contained keys ['y', 'path'] which did not match
any model input. They will be ignored by the model.
—
Reply to this email directly, view it on GitHub
https://github.com/google-research/frame-interpolation/issues/64#issuecomment-1281247151,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADVE3UJQ4XPNPODOR2IKJQ3WDWHGDANCNFSM6AAAAAARCUXO3I
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


Vi Keybindings

This is a great terminal Interface to ChatGPT. After a first look, it seems to me that adding Vi Keybindings should be relativly easy, since the reedline library already supports this. Are there non-obvious things one needs to consider, or can one basically just replace
https://github.com/sigoden/aichat/blob/bbf3672a5f95c6348600029caf1f48a52813fb62/src/repl/init.rs#L58
to use default_vi_keybindings? Thank you!

This seems to work: https://github.com/powellnorma/aichat/commit/5494ae720eba5e6946a8874df2667e1eab31cf21


Allow for optimistic channel handshake

Closes: #2910
Description

PR author checklist:

[x] Added changelog entry, using unclog.
[ ] Added tests: integration (for Hermes) or unit/mock tests (for modules).
[x] Linked to GitHub issue.
[x] Updated code comments and documentation (e.g., docs/).
[ ] Tagged one reviewer who will be the one responsible for shepherding this PR.

Reviewer checklist:

[ ] Reviewed Files changed in the GitHub PR explorer.
[ ] Manually tested (in case integration/unit/mock tests are absent).

What's the best way to test this?

What's the best way to test this?

Sorry I should have mentioned. I start two chains, create clients, connection and channel in INIT state then start the relayer. The config has connection and channel mode enabled. Here are the commands:
hermes create client --host-chain ibc-0 --reference-chain ibc-1
hermes create client --host-chain ibc-1 --reference-chain ibc-0
hermes tx conn-init --dst-chain ibc-0 --src-chain ibc-1 --dst-client 07-tendermint-0 --src-client 07-tendermint-0
hermes tx chan-open-init --dst-chain ibc-0 --src-chain ibc-1 --dst-connection connection-0 --dst-port transfer --src-port transfer
hermes start

Let hermes run for a bit then check the channel and connection states and make sure they are opened.
We should write some integration tests for this.

We should write some integration tests for this.

@ancazamfir I am happy to take care of this if you want?

We should write some integration tests for this.

@ancazamfir I am happy to take care of this if you want?

That would be great! I just committed something I had locally if you want to take it from there, or just discard and rewrite.

I just found that in the case hermes is started before the chan-open-init step things won't work. I think restoring channel from event also needs some changes.
Will move back to draft until I figure it out.


Prim's Algorithm- Graph

Desciption
Prim's algorithm for Minimum Cost Spanning Tree
Programming Language

[x] C++

@ravikr126 @sameeksharl please assign me this issue in C++

Already in repo


Events greater than half hour that are set to 11:30pm go to All Day

Hi,
While this is a rare case, if you have an event that is an hour or longer, and then drag that event in day view to 11:30pm, it turns that event into an all day event. Is there a way to disable this? As I would like the remaining time for the event to spread over to the next day?
Thanks

There is not a way to display events like that at the moment, but there is an effort to add it in #496


In android simulator, searcher bar can not show.

In android simulator, searcher bar can not show.

hi, @jonahzheng thanks for reporting this.
Is this happening on emulator only,
also it could be helpful if you could share some code for the same.
Thank you.

@Atul-pietech I test this app,
https://play.google.com/store/apps/details?id=dev.getflutter.appkit

Thank you @jonahzheng , we are working on our playstore GetWidget demo app. We will update/fix it very soon.


Move all legacy JS into client folder

This allows us to start refactoring these bits to use modern JS. Each file is now a new webpack entry point, but we can combine these into larger bundles in a future PR.

Looks like that code might need a bit of cleanup as it wasn't being linted previously. The main thing being the indentation level of the client folder is 2, but most of the files in wagtailadmin/js were indented at 4.

Merged in 27133f957074635bf6efe461eff9f61d206d8443.


runtime: os.File.Close does not interrupt os.File.ReadAt

Since CL https://golang.org/cl/41670 os.File.{ReadAt,WriteAt} do not use poller. However os.File.Close logic for interrupting in-flight IO currently works only when poller is used. Quoting https://github.com/golang/go/issues/19586#issuecomment-296984259:

In the context of #7970 I've noticed that the actual syscall.Close happens in FD.destroy which itself is called from under last decref. This is ok when poller is used - there awaiting for IO goroutines are first deregistered by pollDesc.evict but in case of blocking IO without poller (ReadAt case) FD.Close will only mark fd mutex as closed (so issuing new read/write requests will not be possible) but e.g. pread request that is already in flight won't be interrupted.
In case where pread could be blocking potentially indefinitely long (networked filesystems, slow IO with retries, ...) that could lead to deadlocks when client code expects Close to interrupt IO, then waits for goroutine doing IO to complete.
So what is the plan here? (offhand I would say that at least for fds not using poller syscall.Close should be called by FD.Close itself with protection from #7970-style races)

Spawning this from #19586 not to forget this problem exists.

In my testing, if I open a pipe in normal blocking mode, read from it in one thread, and then close it from another thread, the read is not interrupted.  It simply hangs indefinitely.  So as far as I can tell the situation you describe was broken before and it's broken now.  I don't see how to fix it.
The GNU/Linux man page for close says
It is probably unwise to close file descriptors while they  may  be  in
use by system calls in other threads in the same process.  Since a file
descriptor may be reused, there are some obscure race  conditions  that
may cause unintended side effects.

While I think we can probably handle the race condition, that also suggests that closing a file does not interrupt any existing I/O on that file.

@ianlancetaylor thanks for feedback. What you say about traditional close semantic is also true for sockets. However the issue here was submitted with Go's net.Conn.Close semantic in mind where Close interrupts all currently blocking Read or Write. With recent generalization of runtime poller pipes should now be also handled in non-blocking / epoll mode so the question here really remains only about "regular" files - those that are rejected by epoll.
While it is tempting for me to say that like in https://github.com/golang/go/issues/19586#issuecomment-298350102 IO on regular files should be alway really "non-blocking", and thus no cancellation is needed at all, I cannot ignore the fact of FUSE use case and when we already had deadlock where both server and client were tested as part of one process:
https://github.com/golang/go/issues/19563#issuecomment-287920797
https://groups.google.com/forum/#!msg/golang-nuts/11rdExWP6ac/UnP5P5m3VPEJ
With Close it can be a similar situation: Read request is made; a filesystem there really blocks somehow (NFS / FUSE / ...) but the syscall is handled via bocking way. If Close does not interrupt it - there is simply no way to cancel it.
I can imagine interrupting syscall from another P from Close via sending a signal. Offhand this should involve at least some synchronization via fdmu so that the signal is always processed before actual IO operation returns. I'm not sure such complications would be accepted though.

I don't think the deadlock mentioned above is possible here.  The deadlock referenced was due to using RawSyscall rather than Syscall.  That doesn't happen here.
I'm going to close this until we have a test case.


Test multi redirect files with docs-verifier

Hi @gewarren - how did the test go? Is everything working as expected? I wasn't sure if the tool that you updated recently correctly discovered all redirection files, that might be something we'd need to update if this doesn't work as expected. Let me know, and I can help with that too if needed.

Hi @gewarren - how did the test go? Is everything working as expected? I wasn't sure if the tool that you updated recently correctly discovered all redirection files, that might be something we'd need to update if this doesn't work as expected. Let me know, and I can help with that too if needed.

This PR is a test for updating that tool (docs-verifier) - not for testing that multiple redirection files work in OPS. So I'm currently working on updating the tool. Getting there.

This is working as expected now.


Installer: binary architecture mismatch on osx

on osx, x86_84, the donwloaded latest binary is arm64
$ wget http://vorc.s3-website.us-east-2.amazonaws.com/iroh-darwin-x86_64-latest
--2024-01-09 10:27:57--  http://vorc.s3-website.us-east-2.amazonaws.com/iroh-darwin-x86_64-latest
Resolving vorc.s3-website.us-east-2.amazonaws.com (vorc.s3-website.us-east-2.amazonaws.com)... <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, ...
Connecting to vorc.s3-website.us-east-2.amazonaws.com (vorc.s3-website.us-east-2.amazonaws.com)|<IP_ADDRESS>|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19422136 (19M) [binary/octet-stream]
Saving to: 'iroh-darwin-x86_64-latest'

iroh-darwin-x86_64-latest         100%[==========================================================>]  18.52M  8.20MB/s    in 2.3s

2024-01-09 10:28:00 (8.20 MB/s) - 'iroh-darwin-x86_64-latest' saved [19422136/19422136]

 ~ took 2s
$ file iroh-darwin-x86_64-latest
iroh-darwin-x86_64-latest: Mach-O 64-bit executable arm64

@Arqu can you take a look please?

This is now fixed.


Clarify and update CF rules for deprecating content

The paragraph in the CF rules document that discusses deprecation is focused on recent (or even the most recent) changes and versions. The rules for deprecation should be updated and clarified for other situations. For instance, a deprecation in issue #314 impacts text that has been part of CF since version 1.0.

Dear @ethanrd
When we added that part to the rules, this situation had never arisen. I believe this is the first time. As I said in https://github.com/cf-convention/cf-conventions/issues/314, I think that the aim of deprecation should be to discourage faulty data from being written, and it should be the minimal recommendation that would achieve that effect.
Cheers
Jonathan

Dear Klaus et al.
@zklaus commented as follows in https://github.com/cf-convention/cf-conventions/issues/314:

I was a bit confused by how the term deprecation was used by @davidhassell and @JonathanGregory, so I searched for it in the issue, finding that I myself introduced it here. Allow me to clarify how I understand it.

Deprecation doesn't apply to versions of an artifact, be it a software package or a standards document. Rather, it applies to specific features. What it says is: "We think this feature should not be used going forward. To allow for a transition period, we do not remove it at this point in time, so you can still use it for a bit, but we'd rather you don't, and we want to remove it in a later version." In my mind, it does not retroactively declare past versions wrong, and writing a new file today that declares that it follows the CF conventions version 1.6 is perfectly legal, if ill-advised.

Independent of any deprecation, we might want to have a recommendation to always use the latest version of CF available for new developments.

Maybe we didn't use the word "deprecation" correctly in the rules, where we wrote:

If the change, once implemented in the conventions, subsequently turns out to be materially flawed, meaning that data written following the convention could be somehow erroneous or ambiguous, a github issue should urgently be opened to discuss whether to revoke the change. If this is agreed by a majority of the committee, a new version of the conventions will be prepared immediately, with the second digit of the version number incremented, and will be recommended to be used instead of the flawed version. The flawed version will be deprecated by a statement in the standard document and the conformance document. However, any data written with the flawed version will not be invalidated, although it may be problematic for users.

As Ethan has said, in this case there is no change to be revoked - we hadn't anticipated that we would discover an error that affects all existing versions! Nonetheless, the principle ought to apply. Data written with the flawed versions (all existing ones) is still legal, but might be problematic, so we want to minimise the use of these versions for new data. In my opinion, we are saying retroactively that all these versions are wrong - not everything which is legal is right, after all! To deprecate something means to express disapproval of it. That is what we are doing. We disapprove of all these versions, but only as regards the specific feature we are correcting. Hence my proposal that we deprecate the versions <1.9 in this feature only.
Best wishes
Jonathan

Hi all - As I mentioned in issue #314, there are a number of deprecations in the current CF specification. Two involve backwards compatibility with COARDS and have been in CF since version 1.0, one of these involves non-compliance with Udunints and the other with temporary(?) deprecation in the NUG. The rest are more recent changes.
Here’s the list of the deprecations currently found in CF 1.9-draft:

“The units level, layer, and sigma_level are allowed for dimensionless vertical coordinates to maintain backwards compatibility with COARDS. These units are not compatible with Udunits and are deprecated …”

Paragraph four of Section 3.1. Units
Similar text in Section 4.3.2 Dimensionless Vertical Coordinate
Since CF 1.0

The standard name modifiers number_of_observations and status_flag are deprecated in favor of standard names number_of_observations and status_flag

In Appendix C: Standard Name Modifiers
Added in CF 1.7

The use of projection_x_coordinate and projection_y_coordinate standard names are deprecated for use with the “geostationary” grid mapping. Instead projection_x_angular_coordinate and projection_y_angular_coordinate standard names should be used.

See Appendix F: “Grid Mappings” Section “Geostationary projection”
Added in CF 1.9

The use of standard_parallel and scale_factor_at_projection_origin attributes are marked as deprecated (without explanation) for use with the  “lambert_cylindrical_equal_area” grid mapping

See Appendix F: “Grid Mappings” Section “Lambert Cylindrical Equal Area
Added in CF 1.7

The missing_value variable attribute - originally allowed for backward compatibility with COARDS but deprecated by NUG and then reinstated in later versions

CF 1.0 through 1.6, considered deprecated by NUG but allowed in CF for backward compatibility with COARDS.
CF 1.7 reinstates the use of the missing_value variable attribute

No discussion of why. Was there a NUG update?

See two items in Section “Revision History”

Hello,
Is it right that the deprecations that Ethan lists (https://github.com/cf-convention/cf-conventions/issues/328#issuecomment-846140071) are still allowed? i.e. these are not wrong, but are discouraged. This is a different situation to #314, for which the formula terms was wrong and it's old form is, from this time onwards, disallowed (is that the right word?) when writing CF<=1.8.
Perhaps we need an appendix to summarize this sort of information - deprecations and errors - as well as in the relevant parts of the text, for maximum visibility (I have a feeling this has already been suggested - but I can't find where!).

Dear @ethanrd and @davidhassell
I would say that the conformance document should provide our definitive list of deprecations. A "deprecation" there is a recommendation not to do it; the CF checker gives a warning about any recommendation that can be checked and isn't followed. Any deprecations that are mentioned in the text should be in the conformance document. Maybe not all of those Ethan has detailed are in it, but they should be, I would argue. The first one is there, for example (in section 3.1 of conformance). Not all of them can be checked automatically, or not easily, but they should still be stated anyway, I think.
The deprecation of flawed versions, like in https://github.com/cf-convention/cf-conventions/issues/314, is different. In this case, we have identified an error in the convention, which allows metadata to be written that can't be interpreted reliably. In the other cases, there's nothing actually wrong, and the recommendations are made with the aim of writing metadata which is easier to use in some way.
Best wishes
Jonathan

I agree the deprecation in #314 is different than those currently in the specification. Perhaps deprecation is not the right word for this usage. Maybe instead errata or corrigenda?
Whatever words we use, I'm not sure CF should (or how it would) "disallow" the #314 deprecation in earlier versions of CF. Any existing data written using this feature would have been conforming at the time it was written. To now make that data non-conforming does not seem right. On the other hand, a simple warning does not seem enough.
Perhaps CF needs a few categories of deprecations:

Current CF Deprecations: still allowed but discouraged (with a conformance warning in all future CF versions). Never to be disallowed.
Standard Deprecation: still allowed but discouraged (with a conformance warning, future CF versions may raise an error).
Error CF Deprecation: disallowed in future versions (with a conformance error). Back-ported to earlier CF versions, very strongly discouraged (with a conformance [very strong??] warning).

(I'm not sure this really helps as what does "very strong error" really mean. Written in all caps and bold text?)

Dear @ethanrd
I would favour simplicity. At the moment, we have two categories in the conformance document. (1) Recommendations to do something. A recommendation not to do something is a deprecation. The CF checker gives warnings for recommendations (including deprecations) that are not met. (2) Requirements to do something. A requirement not to do something is a prohibition. The CF checker gives errors for requirements (including prohibitions) which are not met. I feel that this is sufficient, provided we make sure all the recommendations and requirements in the standard are included in the conformance document. We can't foresee what will happen in future versions of the convention.
Maybe we should make the https://github.com/cf-convention/cf-conventions/issues/314 deprecation into a prohibition instead i.e. disallow (as you say) the flawed old version of "sigma over z"? Then the checker would give an error if it detects it. We could make clear in stating the requirement that it applies to new data (from now on), and does not invalidate existing data (although such data may unavoidably be problematic).
Best wishes
Jonathan

TLDR: My opinion is that the rules are sound for correcting errata, but we do not describe what to do in the case of deprecation. This may not be necessary because we could consider deprecation normal care and feeding for the standard. I do agree that we should have a list of deprecations and the CF Checker should warn of deprecated features. We could consider deciding upon and announcing versions at which we will remove deprecated features.
Musings:
I too prefer simplicity, when it's possible. Would it be possible to use the deprecation mechanism differently for 2 classes of items?:

Errata
Discontinued features

My reasoning here is that we would remove these items from the standard with different speeds.
As @JonathanGregory highlights, there is a procedure for errata (abridged by me):

If the change... turns out to be ... flawed, ... a new version of the conventions will be prepared immediately, with the second digit of the version number incremented, and will be recommended to be used instead of the flawed version. The flawed version will be deprecated by a statement in the standard document and the conformance document. However, any data written with the flawed version will not be invalidated, although it may be problematic for users.

This remains reasonable in my mind, and it would be used in the case that quick action is needed.
Then there are deprecations like @ethanrd notes - I'll speak to the use of projection_x_coordinate and projection_y_coordinate in conjunction with the geostationary grid mapping, as I was involved in that one. That is a feature discovered to be erroneous and deprecated by us. However, we've been living with this error for many years now and nobody complained - the deprecation was due to an (over-) abundance of precision. Thus we have not yet set a date at which mention of those attributes will be completely removed from that part of the standard; it is not urgent.
We could adopt the same approach if we ever have a feature that is overly complex and we no longer want to support the use of it - I'm not advocating this, but for the sake of argument let's say it's the use of packed data described in Section 8.1. In that case, we could deprecate the feature, and even inform users with e.g. 2 releases of notice that it will at some point disappear from the standard. In this case it would not be due to an error, but we could treat it the same way.

Dear all
I'd like to repeat my earlier points that

We should make use of the existing list, namely the conformance document, for the purposes being discussed here - I don't think we need a new list.

We don't have to distinguish positive and negative categories, because they are logically related: prohibition = negative requirement, deprecation = negative recommendation.

Does anyone disagree with those points, I wonder?
Which of these categories should be used if we discover a flaw in the convention, which allows metadata to be produced that can't be interpreted correctly or reliably (as in https://github.com/cf-convention/cf-conventions/issues/314)? The rules say "deprecate" but I think now that's too weak. We should prohibit the use of the flawed convention (not the whole version, just the affected part) for writing new data (but also reassure users that existing data isn't being invalidated).
I appreciate the arguments about the need for a further distinction, and I agree this could help in other cases. I suggest that we need to distinguish between recommendations which are made for good practice (and could remain for ever), and recommendations which are made because there are alternative ways to do something where one is preferred and the other might be abolished in future. That is, we would have three categories in the conformance document, rather than two. An example of a good-practice recommendation in the conformance document is "The name of a multidimensional coordinate variable should not match the name of any of its dimensions." We do not envisage making this a requirement.
In general, we do not try to foresee the future of the CF convention, so I think most of the current recommendations are for good-practice. There should only be a few where we think it's really likely that we are going to abolish something in future. I note that, up to now, we have not abolished anything. One reason for that is because past data continues to exist for a long time. Therefore it's hard to withdraw support for any feature in data-reading programs without causing inconvenience, although you can in data-writing programs. I know that you can always inspect the Conventions attribute, but most user programs don't pay attention to that, I imagine, and we should avoid making things awkward for users.
Hence I would suggest identifying which current recommendations in the conformance document, or which should be in it but aren't, ought to be promoted to a new category of things which really might become requirements/prohibitions in future. What could this new category be called? Warnings?
Best wishes
Jonathan

Dear @zklaus

We don't have to distinguish positive and negative categories, because they are logically related: prohibition = negative requirement, deprecation = negative recommendation.

Sorry to be unclear. I meant by this to explain that the conformance document has only two categories, viz. recommendation and requirement, and that we don't need to have deprecation and prohibition as two more, because a prohibition is a kind of requirement and a deprecation is a kind of recommendation. Does that make sense?
I agree it is possible that we should remove some features when there is an alternative better way, but I think there has to be a strong case for it. Personally, being mostly a data-analyst and data-producer, I think we should favour making it attractive and easy for data-readers and data-writers to use the conventions (correctly, of course, and not carelessly), even if that makes a bit more work for authors of software. That is because writers of widely used software are generally software experts, whereas producers and analysts of data are generally not software experts.
Again I would suggest that a helpful way to proceed would be to identify any current deprecations (recommendations against doing things) in the conformance or conventions document where there could be a strong case for removing some feature in future. Then we will see how large an issue it is, which will help us to decide how to deal with it.
Best wishes
Jonathan

Picking this up again:
from above:

we don't need to have deprecation and prohibition as two more, because a prohibition is a kind of requirement and a deprecation is a kind of recommendation.

Yes, but deprecation is a very specific kind of recommendation -- it recommends you don't use the thing that's deprecated, but it very explicitly states that it might go away, at some time in the future.
I think:
"this isn't a good idea"
is different than
"this isn't a good idea, and it will not work in the future" -- even if "future" isn't currently defined.
But most critically, if we EVER want to be able to remove anything some day (CF 2) -- we will need to be able to clearly define that there's been a deprecation period -- be able to say "you were warned".
And even if we have no idea when that breaking change will actually occur, it would be good to start preparing now -- if there's a feature we'd like to remove, let's deprecate it now.
So yes:

a helpful way to proceed would be to identify any current deprecations (recommendations against doing things) in the conformance or conventions document where there could be a strong case for removing some feature in future.

That's the next step.