Add zsh completion for log options

Add completion for log options.
But I have a question, are env, labels and tag available for all log drivers or only for a few ? It's a little bit hard to understand in log driver docs.
@vincentbernat
Signed-off-by: Steve Durrheimer<EMAIL_ADDRESS>

@sdurrheimer env and labels are for json-file, journald, gelf and fluentd. For tags, I'm not sure :sweat_smile:.

Hm, I'll have to check as well. I wonder if we should just "assume" a driver supports all non-namespaced options (I.e. the options that are not prefixed with the driver-name), and make it a responsibility of the user to read the docs to check if the driver supports the flag (if a driver doesn't support it, will it silently be ignored). I can imagine all these options are a nightmare to maintain in the completions

I wonder if we should just "assume" a driver supports all non-namespaced options

let's assume that in the completion, it will make our lives much easier.

Do we agree on making env labels and tag global log options in zsh completion even if those options are not necessarily used by all log drivers ?

@sdurrheimer sgtm, I think that'd make it a lot easier to maintain

@sdurrheimer @thaJeztah It really depends if those flags are ignored or if they make the command fail :sweat_smile: .

In bash completion, these options are not global: https://github.com/docker/docker/blob/master/contrib/completion/bash/docker#L331-L337.
(I'm not sure if this matrix is really correct, though.)
This makes me wonder whether both completions have to behave identically here. IMHO, not necessarily. For bash, I think we should keep the working solution. For zsh, a pragmatic approach with global options might be good enough.

Thanks for your input @albers, yes ideally, the options should match the actual situation, but I can live with doing it on a "best effort" base, and defining them globally

@thaJeztah The current version is without global_options, similar to what @albers has done with bash.
But I can modify it to make env labels and tag global if you want me to.
(I need to rebase before merge)

@sdurrheimer I'm good with the current approach (it's the "better" solution, albeit more demanding on maintenance), we can move to global options if it becomes to hard to maintain (just my 0.02c)

Ok rebased.
@vincentbernat for review.

Wouldn't it be easy to move the whole log-options state handling into the __docker_log_options function? $opt_args should be accessible directly from the function.

I've done a little refactoring.

LGTM

tag, env and labels added for splunk driver as requested in https://github.com/docker/docker/pull/17891
@thaJeztah

LGTM 🐮
We probably should wait for #17891 to be merged though, right ? :stuck_out_tongue_closed_eyes:

Good to me

LGTM


Hash Partitioning out of UDF seems to be incorrect

We saw in the workflow that UCLA folks were running on cherry01 that the results were arbitrary. The issue happens if the HashJoin receives input from UDF.

Discussion 2022.12.07: @shengquan-ni will take a look.

In short, this issue arrives for a join operator, when one side of input is transferred from Java, and another side is transferred from Python. Although the data from both sides are hashing on the same columns, because of the differences in the hash functions in Python and Java, the workers of the join operator cannot receive the same partitions.
After discussing with @Yicong-Huang and @shengquan-ni , we agreed on the following idea:

It is very difficult, if not impossible, to replicate the exact same hash function in both Java and Python, so we will not try this effort. Therefore, the shuffling from Python to Join must be also implemented in Java to get a consistent hashing.
This does not mean that we will abandon the shuffling system in Python. Instead, we detect specific cases like this, and only perform shuffling in Java when necessary. All most cases, such as Python to a single-input operator, or Python-to-Python, shuffling will still be done in Python.

The implementation plan will be as follows:

In this specific case, we will create an no-op operator between Python and Java. The no-op operator does not handle any processing logic. As soon it receives any data from Python, it will be immediately shuffled out.
We'll detect this case in the workflow compiler layer. Specifically, we detect (1) a multi-input operator requires shuffling, and (2) the operator and inputs run on different platforms. After the detection, we (1) change the original input operator's output policy to not perform shuffling, and (2) insert an no-op operator with a shuffling output policy.


v1.9 backports 2021-10-04

#15450 -- agent: Silence some useless warnings (@tgraf)
#16969 -- docs: clarify language on libceph and kernel 5.8 in kubeproxy-free GSG (@bluikko)
#16264 -- docs: Fix command for overwriting iptables on kube-proxy replacement install (@Stijn98s)
#17424 -- contrib/backporting: add environment variables to set ORG and REPO (@aanm)
#17417 -- pkg/k8s: fix User-Agent for kubernetes client (@aanm)
#17489 -- test: bump coredns version to 1.7.0 (@aanm)

PRs skipped due conflicts:

#17477 -- helm: set correct versions of docker images in Makefile (@aanm)
REASON: Workflow file doesn't exist.

Once this PR is merged, you can update the PR labels via:
$ for pr in 15450 16969 16264 17424 17417 17489; do contrib/backporting/set-labels.py $pr done 1.9; done

or with
$ make add-label branch=v1.9 issues=15450,16969,16264,17424,17417,17489

/test-backport-1.9


How can I set 'view build and release pipeline' as default permission for my Azure DevOps project?

We want to publish a public facing project in Azure DevOps to let users see source code and how pipelines are configured. However 'view pipelines' is disabled by default. How can we enable that for everyone?

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

ID: 7f8c8539-89a7-a426-868b-96e961c39e29
Version Independent ID: de260a68-aab7-7c6b-6727-90c92c65b225
Content: Azure Pipelines New User Guide - Key concepts - Azure Pipelines
Content Source: docs/pipelines/get-started/key-pipelines-concepts.md
Product: devops
Technology: devops-cicd-get-started
GitHub Login: @juliakm
Microsoft Alias: jukullam

Sorry I referred to the wrong doc. Close this one.

I have created another one under the right doc.


ghp-import in circle

Not waiting for tests because this change will only occur on the master branch


fix(nav): app crash on procrastinate recovery

Description
On iOS when a user would procrastinate during the recovery phrase setup flow the app would crash.
Video Before
https://github.com/valora-inc/wallet/assets/26950305/1f5cd7d6-cfee-41c5-a74a-633e4efd954c
Video After
https://github.com/valora-inc/wallet/assets/26950305/387adf69-79d7-4e0c-b10a-2f6591dec421
Test plan
Tested with the following reproduction steps

Complete the onboarding flow with new account
After landing on the home screen navigate to ‘Recovery Phrase’
Navigate to this flow until you are viewing your recovery phrase.
Tap ‘Cancel’ and ‘Setup Later’ to exit the flow
Observe app crash.

Related issues
N/A
Backwards compatibility
Yes

@jeanregisser the issue is we cannot call navigateHome from within a modal as navigateHome resets the navigation state; disposing of the currently active screen which appears to cause a null pointer dereference error within the modal. To test this if we can add a setTimeout prior to calling navigationHome and if the modal is dismissed prior to calling and there is no crash.
There's some existing code that hints at this and it was confirmed through testing on the Dialog modals in src/account/Settings.tsx. I'll add some docs for navigateHome and modal usage.


Integrate codecov.io in odo OpenShift CI job

/kind user-story
User Story
As a odo team we want to integrate codecov.io with CI So that we can measure unit test coverage on prs.
Acceptance Criteria

[ ] We should see codecov comment on pr with unit test coverage percentage

Links

Feature Request: NA
Related issue: NA

/kind user-story

We removed this in https://github.com/openshift/odo/pull/4628. Can you elaborate on what we might be able to do here?

/close
we use sonarcloud to track coverage now


feat: client-side commands

This is easy enough to hack outside puppeteer, but I was just wondering if there is an easy way (or if it could be added) to use commands from the client, i.e. something like:
page.evaluate(() => {
  page.click('.foo')
})

@pemrouz - not sure what exactly you meant in your example, but the correct way to use click is:
page.click(selector)

(no need for the evaluate here)
If you want to run code in browser context you can just run it using:
page.evaluate(() => code to run in browser)
Can you explaign what exactly did you look for?

@pemrouz Are you wanting to run Puppeteer scripts inside the browser itself, instead of running from Node?

The browser and Puppeteer have different context. U can't run puppeteer's scripts in browser directly.But u could do like this
const clicker = await page.$('.foo')
await clicker.click()
await page.evaluate(() => {}) // something happen after foo clicked


Implement From for Stdio

Fixes #49

Thanks for the feedback! Unfortunately, I no longer have a use case for this feature and this PR is 2 years old, so I doubt it will be merged. Anyway, if someone decides to fork the project and find this feature useful, I'd be happy to contribute.


[3pt]  - Add tests for items counter - Student A

Make sure that function for the items counter is covered with unit tests using Jest.

https://github.com/businesskaniki/microflix/pull/41


Fix input images types in UI generation

The changes in #103 expect image id's passed into the workers to be files rather than items.  This PR makes the corresponding change in the UI code.  The result is still a little bit hacky because I can't return the svs file produced by the the large image plugin for the end to end demo.  Instead, I have to use the original png.  Once the workers can read svs, we should fix this line.
I also made two other small changes:

Input images now default to the currently displayed image.
Fixed a couple of small bugs in the header rendering.

@manthey Can you please QA this?

LGTM.  I'll update with master.  Since @jbeezley is away for a while, after travis is happy, we should merge it in.


Cannot create pod after restart crio service

Description
The command crictl runp test/testdata/sandbox_config.json cannot run successfully after restart crio service, but if restart the crio service twice, it returns to work again.

Steps to reproduce the issue:
Below steps are executed one after one immediately.
[root@localhost cri-o]# systemctl restart crio
[root@localhost cri-o]# crictl runp test/testdata/sandbox_config.json
806c14a58b59ee5c8ea28663386270d8ba43536fa8967f0602e8d30beaeecee6
[root@localhost cri-o]# systemctl restart crio
[root@localhost cri-o]# crictl runp test/testdata/sandbox_config.json
FATA[0003] run pod sandbox failed: rpc error: code = Unknown desc = conflict, name "k8s_podsandbox1_redhat.test.crio_redhat-test-crio_1" already reserved for pod "806c14a58b59ee5c8ea28663386270d8ba43536fa8967f0602e8d30beaeecee6"
[root@localhost cri-o]# systemctl restart crio
[root@localhost cri-o]# crictl runp test/testdata/sandbox_config.json
ae2f950d7ee03d71a2b803adfe5d8ca80bfe014dd975e5074ef28def5d75f900
[root@localhost cri-o]# systemctl restart crio
[root@localhost cri-o]# crictl runp test/testdata/sandbox_config.json
FATA[0003] run pod sandbox failed: rpc error: code = Unknown desc = conflict, name "k8s_podsandbox1_redhat.test.crio_redhat-test-crio_1" already reserved for pod "ae2f950d7ee03d71a2b803adfe5d8ca80bfe014dd975e5074ef28def5d75f900"

Describe the results you received:
cannot create pod after restart crio service
Describe the results you expected:
it can create pod no matter how many times the crio service is restarted
Output of crio --version:
[root@localhost cri-o]# crio -v
crio version 1.9.0-dev
commit: "cb8033cd194bb98170d715b6f8ce873550d78706"
[root@localhost cri-o]# crictl -v
crictl version 1.0.0-alpha.0

If cri-o restarts and you want to run the same pod again you have to increment the Attempt or delete and recreate the same pod.
Does that mean if I didn't update Attempt and continue create the same pod, we should failed to create the pod?

Currently, without update the Attempt, the same pod can be created continually

But after restart the crio , failed with "run pod sandbox failed: rpc error: code = Unknown desc = conflict, name "k8s_podsandbox1_redhat.test.crio_redhat-test-crio_1" already reserved for pod "f84c4518365d457e9cf3002dee2ff7c631cb22a1e0997e2713442cd1b4bb46b4" "
@runcom

@gouyang @runcom Do we still have this issue?

Test on the master, not an issue any more.


Fix a typo roboto, code had ".tff", instead of the correct ".ttf"

Here are the steps to identify the problem:

In Firefox debug console with some website, this problem creates warnings such as
downloadable font: no supported format found (font-family: "Roboto" style:normal weight:400 stretch:100 src index:1) source: (end of source list)

In Stylesheet editor this manifests itself as something like:

    @font-face {
      font-family: Roboto; -moz-osx-font-smoothing: grayscale; -webkit-font-smoothing: antialiased;
      font-style: normal; font-weight: normal; src: url(moz-extension://93af..............93c24/Roboto-Regular.tff) format('tff');
    }

Opening moz-extension://93af..............93c24/Roboto-Regular.tff gives an error
Opening moz-extension://93af..............93c24/Roboto-Regular.ttf gives a font!

Therefore I suggest this fix.
Hopefully it will be applied even if it's not an urgent PR.

Thanks for the fix!


15.0.0 release?

The LLVM 15.0.0 release has been out for a week now, but the latest stable clangd release is still 14.0.3. There is a 15.0.0 release for clangd, but it is marked as Pre-release. This means that the VS Code extension doesn't auto-update to 15.
Just wondering if this is intentional, or if there was maybe some manual step that somebody forgot to do...

yes this is intentional, we're testing out the release "manually" during our regular development to see there are no regressions that slipped away before shipping it to everyone. we'll probably send it to everyone before the end of the month if we don't encounter any big regressions

I've marked the release as stable now, it seems to be good to go.
(Had to rebuild it - there was an accidental dynamic dependency on zstd, which could cause clangd to fail to start on machines without zstd.{so,dylib,dll}.)

Just wanted to say thank you for your guys' good care.
Cheers,
Chris
[I remember I had this question once upon a time, and smiled seeing this issue.]


Key binding for openToSide?

Is it possible to define a key binding for the openToSide-action - or is there any? :-)

In the Ctrl+P list, I use Ctrl+Enter. Otherwise I use Ctrl+2 quite a lot.
@bpasero : Should there be a hover showing the keybindings?

Hmm, didn't i try that? :-) works great - thanks.... 👍

👍


Login Page issue resolved

Issue number #68
I have improved UI of login page. It also has validations.
Sign page also have same problem, I have created an issue #166 for that, please assign me that so that I can complete both the pages.
Before

After

Is is responsive ?
Attach Mobile version screenshot too. And then create PR again.

Yes, it is responsive.


feat: async callbacks

Callbacks PoC
This draft showcases a complete callback flow where a call originates on the origin chain, triggers execution on a destination chain, and then returns the result to the origin chain, where it is handled with custom logic.
The flow is as follows:

Possible Next Steps

Having a dedicated library to abstract functionality and facilitate the interaction would be a valuable addition to the ecosystem.

Possible Future Improvements

Flexible Callback Contexts: Introducing a more complex data structure to support features like expiration times or additional metadata.
Robust Error Handling: Supporting logic to handle both successful and failed callbacks.

Additional Context

Leverages the entrypoints feature

This is awesome!  I did some hacking on something similar here a few weeks back.  I'm curious, what is the motivation for having the entrypoint contract call occur earlier in the call stack than the CDM? Is it to preserve the CDM's cross domain context (sender, chainId, etc) or something else?
In terms of future work -- one thing I came to after hacking was that dependent async calls are probably an important feature.  For instance, I suspect devs often will want to make an async call which gets relayed only after some other L2<>L2 Message (e.g. a SuperchainERC20 transfer), or create multiple async calls, and require that they be delivered in order.

I'm curious, what is the motivation for having the entrypoint contract call occur earlier in the call stack than the CDM? Is it to preserve the CDM's cross domain context (sender, chainId, etc) or something else?

yes! it's to keep the CDM as the "exitpoint" of the relayed messages, abstracting away the extra logic handled via the "wrapper" entrypoint contract

In terms of future work -- one thing I came to after hacking was that dependent async calls are probably an important feature. For instance, I suspect devs often will want to make an async call which gets relayed only after some other L2<>L2 Message (e.g. a SuperchainERC20 transfer), or create multiple async calls, and require that they be delivered in order.

this is exactly why we build the entrypoint primitive!
here is the draft idea (Design 2 is the way to go imho): https://gist.github.com/0xParticle/5119cfa271a6fba6ae8b7649e0bba5db


Add some more text about notebook UI

WIP. Discussing with @greazer

Codecov Report

Merging #6871 (33a2f4a) into main (04dd691) will increase coverage by 0%.
The diff coverage is n/a.

@@          Coverage Diff           @@
##            main   #6871    +/-   ##
======================================
  Coverage     68%     68%
======================================
  Files        410     410
  Lines      28522   28522
  Branches    4263    4263
======================================
+ Hits       19441   19590   +149
+ Misses      7404    7231   -173
- Partials    1677    1701    +24

Impacted Files
Coverage Δ

...datascience/interactive-common/notebookProvider.ts
81% <0%> (-6%)
:arrow_down:

.../datascience/jupyter/kernels/cellExecutionQueue.ts
89% <0%> (-5%)
:arrow_down:

src/client/common/process/pythonDaemonPool.ts
75% <0%> (-5%)
:arrow_down:

...cience/jupyter/jupyterCellOutputMimeTypeTracker.ts
84% <0%> (-4%)
:arrow_down:

src/client/datascience/jupyter/kernels/kernel.ts
63% <0%> (-3%)
:arrow_down:

...t/datascience/notebook/vscodeNotebookController.ts
79% <0%> (-1%)
:arrow_down:

src/client/datascience/baseJupyterSession.ts
66% <0%> (-1%)
:arrow_down:

src/client/datascience/jupyter/jupyterNotebook.ts
75% <0%> (-1%)
:arrow_down:

...ient/datascience/editor-integration/codewatcher.ts
69% <0%> (+<1%)
:arrow_up:

src/client/datascience/commands/commandRegistry.ts
39% <0%> (+<1%)
:arrow_up:

... and 20 more


How to run

How to run script.
I download Node and install TypeScript.
Command:
D:\github.com\habra\src>tsc index.tsx

is fail(((
Write is this and more
index.tsx:1:24 - error TS2307: Cannot find module 'react' or its corresponding type declarations.

For building a project you run npm run build.
For other scripts you can look up in package.json - you have to run them starting with npm run


Use tauri bundle

Fix: https://github.com/ztjhz/BetterChatGPT/issues/187
The file is now officially built and can be used, and an example is available at https://github.com/jiawei397/FreeChatGPT/releases. These files can be downloaded, installed, and used.
The existing code will not affect the original web usage. If you have local Rust installed, you can use yarn dev:tauri to start and yarn build:tauri to complete the build.
There are several areas that require further processing by the author:

The Github build file github/workflows/release.yml has been set to publish when tagging, and it can be considered for removal. The advantage of Tauri is that it generates relatively small resources, but the disadvantage is that it is also caused by Rust, which is very slow. It takes about 15 minutes in the Github pipeline.
Before each release build, it is necessary to modify the version number package.version in the file src-tauri/tauri.conf.json. It may not be necessary if the technology of detecting version numbers for updating prompts is not used. You can also consider removing the tag title displayed on the release page from the release.yml file. I didn't study this carefully, just found a sample online.
Several icons in the path src-tauri/icons might need to be modified, and currently, the default Tauri icons are being used.
My several download methods all return Promise and might fail (though it is not highly likely). Therefore, when using them on the upper layer, I added a catch method and wrote a TODO, which can be considered to add error prompts there.
Several Tauri exports have been implemented, including the original PDF, but there was an error during packaging. You have already commented out this feature, which was caused by a conflict with topLevelAwait. If you resolve it later, you can annotate my code in src/utils/tauri.ts.

By the way, due to the update of the deploy.yml file, my fork project can no longer be built directly on GitHub and must be restored to its original version. However, regardless of the situation, it's still an excellent job. Thank you.

Amazing work! 🔥

Good job!


Update the logic for ETags and preconditions

https://tools.ietf.org/html/rfc7232#page-13
Based on the RFC specs, there is no null IfMatch precondition.

The "null if-match" condition is just not sending an if-match header. What do you mean it doesn't exist?


Missing git history from coreos-kubernetes/tree/master/multi-node/aws

The first commit message in this repo says:
"Move everything under the multi-node/aws directory from coreos/coreos-kubernetes c25ac21"
But all the commit history from the original location is lost
https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/aws
Could you maybe extract the directory's history?
http://stackoverflow.com/questions/1662753/export-subtree-in-git-with-history
Also, should https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/aws be stopped/blocked if this repo is to become the official location?

Hi @kenden
Thanks for your feedback!
I've just finished recovering the history with the procedure you've provided.
It does seem to work but a gotcha(at least for me) is that, even though it doesn't relate to the procedure, each directory's history doesn't survive git mv so e.g. looking into config/'s history, you'll see that the origin of it is now my git mv commit https://github.com/coreos/kube-aws/commits/master/config
However, the root directory's history is preserved as we might have expected https://github.com/coreos/kube-aws/commits/master so I assume it is still very useful.
Are you satisfied to the result?
Further comments and feedbacks are welcome!
Also, regarding the former repo, would you please wait until coreos guys make an announcement?

Much nicer thanks @mumoshu!
Note it's still possible to get the history of file under config with for ex:git log --follow config.go.
Cheers!

@kenden I wasn't aware of it but --follow did work. Thanks for the tip!

@kenden FYI regarding the former repo, https://github.com/coreos/coreos-kubernetes/pull/751 is WIP

I guess you've probably noticed that the move from the coreos-kubernetes to the kube-aws repo is announced multiple times in github issues. There's also a notice in the very beginning of the README 👍
I'm closing this as the original issues are resolved but feel free to reopen if necessary.
Thanks for your interest and feedback, @kenden!


AsyncStatus class is not valid

The class defined under https://docs.microsoft.com/en-us/azure/cognitive-services/face/face-api-how-to-topics/use-persondirectory#wait-for-asynchronous-operation-completion is not valid:

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

ID: c4df5f96-e61b-ad7a-f0d2-27f8ed88b313
Version Independent ID: 0529713f-772e-978f-c25d-a2adc6d0b6be
Content: Example: Use the PersonDirectory structure - Face - Azure Cognitive Services
Content Source: articles/cognitive-services/Face/Face-API-How-to-Topics/use-persondirectory.md
Service: cognitive-services
Sub-service: face-api
GitHub Login: @PatrickFarley
Microsoft Alias: pafarley

@danzel Thank you for your feedback! We will review and update as appropriate.

@danzel updating AsyncStatus to Status should resolve the issue. I've created a PR to fix this issue. Thanks again!


Add check for templated Opsgenie receiver config

Solves #2887, where Opsgenie responder type can be templated according to docs, but configuration logic checked for specific list of values only.

Hey @simonpasquier. Any blockers to merge this? And any information about when is the next release?


\b doesn't go all the way back on wrapped lines

Windows Terminal version
1.16.10261.0
Windows build number
Version 10.0.19045.2965
Other Software
No response
Steps to reproduce
It's easily reproducible in C. This seems to happen with any writing to the console, WriteConsole, printf, putchar, etc. Just write more letters than you have columns, and try to backspace back. You'll get stuck at the front of a row.
    for (int i = 0; i < 100; i++) {
        putchar('-');
    }
    for (int i = 0; i < 100; i++) {
        putchar('\b');
    }

Expected Behavior
I just want \b to take me back to the previous line if I didn't end the previous line with a \n. The console knows the line is wrapped. I can increase the size of the window and the cursor will pop back up to the previous line.
Actual Behavior
The cursor just gets stuck in the first column and refuses to delete what it just wrote.
 This is really hard to code around. You can't just write to the terminal, you have to query your position every time you want to backspace or line wrapping will break your program.

This is expected behavior for a standard VT terminal. Quoting from the DEC STD 070 Reference Manual for the Back Space control (page 5-63):

The BS control is not affected in any way by the setting of Auto Wrap Mode. Under no circumstances does the Active Position advance to the previous line on reaching the beginning of the Active Line.

It's just really terrible inconvenient to never know if you can use \b. A lot of modern terminals do allow you to upwrap with backspace. I know PuTTY does this and I have a friend who uses iterms2 on macOS that allows it. The Gnome terminal does. I don't know if it really breaks anything since so many modern terminals allow it.
It's too bad the DEC standard made that call, but standards aren't always set in stone and can evolve over time to better serve user needs. I mean, back then they had things like ENQ, ACK, DEL, etc that are all but ignored these days. I took a look real quick and there's lot of stuff that have been left behind from the standard. Here's a direct quote stating double width lines are a required feature:
Page 1-18
1.6.2 Required Functions

The following controls are required for all conforming Level 1 implementations.
...
SINGLE WIDTH LINE
DOUBLE WIDTH LINE
DOUBLE HEIGHT LINE TOP
DOUBLE HEIGHT LINE BOTTOM

I've never even heard of that before. And it's not just on that one page, double width lines are mentioned 26 times. But I'd be willing to bet no one meets that requirement anymore.
I doubt they ever imagined terminals that were vastly different sizes or that could change size on the fly. I'm not saying the DEC STD 070 standard isn't still influential, but terminal emulator developers do make practical decisions about what aspects to implement based on the needs and constraints of modern computing.

I know PuTTY does this and I have a friend who uses iterms2 on macOS that allows it. The Gnome terminal does.

I've just done some testing, and yes PuTTY does this, and so does iTerm2, but the only other terminal I could find that matches that behavior is Rxvt (but not all versions). Gnome Terminal does NOT wrap back onto the previous line. Nor does XTerm. Nor did any of the other 30 or so terminals I tested. I can't imagine we'd choose to side with PuTTY, iTerm2, and Rxvt over everyone else, in addition to ignoring the standard.

double width lines are mentioned 26 times. But I'd be willing to bet no one meets that requirement anymore.

You'd lose that bet. Windows Terminal and Conhost both support it, as does XTerm, MLTerm, Konsole, and like 15 or so other terminals that I'm aware of. I know not everyone cares about standards, but I certainly do, and I would like to improve our standards compliance - not make it worse.

I realize I'm not likely to change your mind, but I'm still interested in the conversation.
The terminals that the DEC STD 070 standards were written for had a fixed width in characters. So you could write your code assuming you had, say, 80 characters. You send a string of text you decided on ahead of time and then safely backspace over it and overwrite it. For example, you could print "Loading..." and then send 10 BS before replacing it with "Successfully loaded."
However, a modern terminal could be just 4 columns wide! Without backspace unwrapping, the previous example is no longer safe. There's no string short enough to safely use backspaces with. You have to check your position every single time you want to backspace and have special code that will take you to the end of the line above your current row instead. I think it's important to keep these interfaces usable and efficient.
I ended up writing my own version of printf/WriteConsole that iterates over each character and handles backspaces differently. So, I guess technically the problem is solved for me, but I don't think the standard would have even introduced a special BS character if they thought it was going to be unreliable.

I can't imagine we'd choose to side with PuTTY, iTerm2, and Rxvt over everyone else

Is it really only those 3? I often run in a screen session so I may have overestimated how common it is since screen supports backspace unwrapping as well. I can't recall screen breaking anything by allowing this, but my point was just that it's already being done. Since some popular terminal emulators allow it, there's already reasonable support for the feature.

You'd lose that bet. Windows Terminal and Conhost both support it

I guess I would lose that bet! I doubt any real terminal supports it but it looks like some virtual terminals do. Even PuTTY supports this:
echo -e "\033#3This is the top half of a double-height line.\n\033#4This is the bottom half of a double-height line."`

I saw screenshots of it in Windows Terminal but I couldn't get it to work myself. How can I test it there? I tried:
Write-Host ([char]27 + "#3This is the top half of a double-height line.`n" + [char]27 + "#4This is the bottom half of a double-height line.")

But perhaps that was a bad example. There's also extensive discussion about printers in DEC STD 070 that I assume no one follows anymore. The word "printer" comes up 852 times. As technology advances and changes, it's only natural that certain parts of these standards become outdated. (Again, a terminal with 4 columns.) I realize there must be some trade off for moving forward but it does seem others have figured out how to do this effectively without breaking backward compatibility with existing command-line tools, scripts, etc.

(I'm going to move this to a discussion - it doesn't seem like there's anything for us to do on our end here, but this has been a really interesting discussion so by all accounts, do go on)


fix(computeresource/tasklevel): Fixed a bug where abnormal calculatio…

Fixed a bug where abnormal calculations caused requested resources to exceed limits when Resource type was Memory or EphemeralStorage

Changes

Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[x] Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
[x] Has Tests included if any functionality added or changed
[x] pre-commit Passed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including functionality, content, code)
[x] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
[x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
[x] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
NONE

/kind bug

/ok-to-test @Ccheers can you detail a bit more what is the issue ? (use-case, or examples)您能详细说明问题所在吗？(用例或例子）

In previous versions, when calling computeAverageRequests, if there was a Memory resource in corev1.ResourceList, it would cause an abnormal calculation of the Memory resource.
eg:

func Test_computeAverageRequests(t *testing.T) {
	type args struct {
		requests corev1.ResourceList
		steps    int
	}

	tests := []struct {
		name string
		args args
		want map[corev1.ResourceName]string
	}{
		{
			name: "get 1 Mi",
			args: args{
				requests: corev1.ResourceList{
					corev1.ResourceCPU:    resource.MustParse("300m"),
					corev1.ResourceMemory: resource.MustParse("32Mi"),
				},
				steps: 3,
			},
			want: map[corev1.ResourceName]string{
				corev1.ResourceCPU: func() string {
					parse := resource.MustParse("100m")
					return parse.String()
				}(),
				corev1.ResourceMemory: func() string {
					parse := resource.MustParse("11184810")
					return parse.String()
				}(),
			},
		},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			got := computeAverageRequests(tt.args.requests, tt.args.steps)
			mm := make(map[corev1.ResourceName]string, len(got))
			for k, v := range got {
				mm[k] = v.String()
			}
			if !reflect.DeepEqual(mm, tt.want) {
				t.Errorf("computeAverageRequests() = %v, want %v", mm, tt.want)
			}
		})
	}
}

// memory need 11184810
// but got<PHONE_NUMBER>6m

@vdemeester


Database efficiency improvement

I believe that removing IDs on what should be weak entities should prove to help in an efficiency increase in the database by instead replacing them with composite primary keys.
An example would be:
model Subscription {
  id String @id @default(uuid()) // this is removed

  roleId                 String?
  discordChannelId       String?
  memberRoleId           String?
  memberDiscordChannelId String?

  relayChannelId String?
  cameoChannelId String?

  communityPostRoleId    String?
  communityPostChannelId String?

  channelId String
  channel   HolodexChannel @relation(fields: [channelId], references: [id], onDelete: Cascade)

  guildId String
  guild   Guild  @relation(fields: [guildId], references: [id], onDelete: Cascade)

  @@unique([channelId, guildId]) //replaced with @@id([channelId, guildId])
}

I'm not very sure about this change so if someone could have a glance over it or test it out it would be extremely appreciated 🙇


My Progress to 1.4

It doesn't have the toggle expert mode thing working because Re-Logic set Main.Hardmode to private, and journey mode code resets it every world update tick. Through reflection I have all the other features working though.

I haven't looked at decompiled Terraria 1.4 yet, so I'm not sure if I can help right now.

Would it help if we disabled the Expert Mode Toggle thing in Journey Mode worlds?
Or, the opposite approach, add another command that toggles Journey Mode?

We could remove it. That would help If we aren't using journey mode but I think that will require IL editing.
I haven't done IL editing but I probably could learn it.

Let's remove the /expert command for now, maybe add that back in a future update.


[SPARK-47127][INFRA] Update SKIP_SPARK_RELEASE_VERSIONS in Maven CIs

What changes were proposed in this pull request?
This PR aims to update SKIP_SPARK_RELEASE_VERSIONS in Maven CIs in order to prevent failures.
Why are the changes needed?

To skip newly released Apache Spark 3.5.1
To remove deleted Apache Spark 3.3.4 and 3.5.0.

Does this PR introduce any user-facing change?
No.
How was this patch tested?
This should be tested after merging.
Was this patch authored or co-authored using generative AI tooling?
No.

If the following PR fails, I'll file a JIRA issue and make this PR Ready.

#45075

cc @LuciferYang and @HyukjinKwon

Thank you, @HyukjinKwon .

Merged to master.

hmm... If ivy 2.5.2 is not upgraded,I think Spark 3.5.1 can be tested and passed ....


Add Back / "X" buttons to the Forms

We need to add a Back / "X" button to each form so the user can return to the dashboard without hitting the back button.

Cancel buttons added to the forms.  We can discuss later if we want to change their appearance / placement.


migrate seeder to cmd/seeder and fix related issues #373

add initial impl for voucher

Codecov Report

Merging #387 into master will increase coverage by 0.01%.
The diff coverage is 27.10%.

@@            Coverage Diff             @@
##           master     #387      +/-   ##
==========================================
+ Coverage   52.34%   52.35%   +0.01%
==========================================
  Files         132      130       -2
  Lines        7499     7392     -107
==========================================
- Hits         3925     3870      -55
+ Misses       3063     3001      -62
- Partials      511      521      +10

Impacted Files
Coverage Δ

pkg/config/consts.go
0.00% <0.00%> (ø)

pkg/config/loader.go
61.03% <ø> (ø)

pkg/core/candidate/validator.go
65.21% <ø> (ø)

pkg/core/consensus/agreement/accumulator.go
90.90% <ø> (ø)

pkg/core/consensus/agreement/handler.go
66.03% <ø> (ø)

pkg/core/consensus/agreement/store.go
59.30% <0.00%> (ø)

pkg/core/consensus/collector.go
0.00% <ø> (ø)

pkg/core/consensus/committee/handler.go
88.88% <ø> (ø)

pkg/core/consensus/component.go
72.41% <ø> (ø)

pkg/core/consensus/event.go
20.00% <ø> (ø)

... and 93 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update af2b466...5332d87. Read the comment docs.


Github page links not working

Hey @eppak thank you for the awesome work.
A thing I noticed after merging the PR is: the links for the single Expirable data structures lead to a 404.
I hope to have some time during the week to check if, but it you manage to find some minutes I'd love to bring in a PR fixing this

Hello @Cadienvan for sure, can you explain me how to reproduce the issue? I tried to run locally and go directly to "/docs/map" and got the page, tried also the build locally.
Thanks

If you get to https://cadienvan.github.io/expirables/ and try to click on any of the links, they bring you to 404 pages: https://cadienvan.github.io/expirables/src/Map/README.md

I found what is going on, if the pull I opened to fix contributors is still open I can commit the fix there (I will rename it to have a better doc of what done on it).

As you are fixing both for yourself go for it!

Hello, I fixed the root readme, was pointing to old md files that I moved to new docs, can you let me know?
Thanks

Resolved in v1.6.6


Added contribution guide

#49
Added contribution guide for the project

I imagine we will make amendments as we go along, for example adding more labels. But for now looks like a good start in our planning phase.


Add RisingWave logo

This PR adds RisingWave logo per instructions at project's README doc.

Hi@pheralb , could you please kindly help merge this? Thanks in advance!

Gentle bump @pheralb
Please kindly let me know if anything is missing to get this PR merged. Thanks again 🙏


[RFC] Proposal for Coefficient adapter classes: VectorElementCoefficient and MatrixElementCoefficient

Following @mlstowell's good example, I was wondering if the MFEM team would have any use for the following adapter classes I'm writing for LLNL's design optimization library:

VectorElementCoefficient: subclasses mfem::Coefficient; it takes an mfem::VectorCoefficient and an integer index i as constructor arguments, and its Eval method would return element i of the VectorCoefficient's Eval method
MatrixElementCoefficient: subclasses mfem::Coefficient; it takes an mfem::MatrixCoefficient and two integer indices i and j as constructor arguments, and its Eval method would return element (i, j) of the MatrixCoefficient's Eval method

Arguably, these methods could be anti-patterns, but I find it useful to compute VectorCoefficient-related quantities like the center of mass or dipole moment as vectors, and MatrixCoefficient-related quantities like the moment of inertia or quadrupole moment tensors to avoid indexing mistakes in these computations. However, the design optimization library's design currently favors decomposing vector- and matrix-valued quantities into individual elements, which is why having these adapter classes is useful for us -- we may only want to bound a subset of components in our optimization problems.

These two classes (VectorElementCoefficient and MatrixElementCoefficient) fit into the same theme as #590 - I think we can add them to that branch - unless @mlstowell has any objections.

No objections.  I think this is a fine idea.  Thanks, @goxberry !

@goxberry, I'm closing this issue, but as indicated above, feel free to add to Mark's branch.


294 fallbackroute should return opt

Please review this PR for #294
It switches Fallback.route to use Opt instead of Iterator

@ekondrashev Thanks for your pull request, let me find someone who can review it

@pinaf this pull request is for you, please review

@pinaf seems like the PR was lost, could you please provide your comments?

@ekondrashev 2 minor comments above

@ekondrashev we need a merge with master

@pinaf I've merged with master and fixed all the comments.
I've also added ClassDataAbstractionCouplingCheck check style warning suppression for FbStatus.java not sure if I need to create a ticket to resolve it as puzzle.
Please let me know if PR needs another changes.

@ekondrashev looks like your merge was not done correctly. there are multiple files that should not have any changes but do..

@pinaf sorry for that, fixed.

@ekondrashev thanks. 2 comments

@pinaf removed the suppression. As for the second comment, yes it is needed, qulice gives
[ERROR] /src/main/java/org/takes/facets/fallback/FbStatus.java[46]: Class Data Abstraction Coupling is 8 (max allowed is 7) classes [Condition, Fallback, Opt.Empty, Opt.Single, RsWithBody, RsWithStatus, RsWithType, TkFixed]. (ClassDataAbstractionCouplingCheck)

without it.

@ekondrashev thanks

@rultor merge

@rultor merge

@pinaf Thanks for your request. @yegor256 Please confirm this.

@ekondrashev one comment above

@yegor256 right, fixed

@yegor256 could you please take a look at this PR?

@rultor try to merge

@rultor try to merge

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

@rultor try to merge

@yegor256 Oops, I failed. You can see the full log here (spent 9min)

Results :

Failed tests:
  BkParallelTest.requestsAreParallel:123
Expected: <0L>
     but: was <1L>

Tests run: 222, Failures: 1, Errors: 0, Skipped: 5

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:50 min
[INFO] Finished at: 2015-06-01T17:46:43+00:00
[INFO] Final Memory: 24M/371M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project takes: There are test failures.
[ERROR]
[ERROR] Please refer to /home/r/repo/target/surefire-reports for the individual test results.
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project takes: There are test failures.

Please refer to /home/r/repo/target/surefire-reports for the individual test results.
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures.

Please refer to /home/r/repo/target/surefire-reports for the individual test results.
	at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:82)
	at org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:195)
	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:861)
	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	... 19 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

@yegor256 could you please give an advice on the error above?

@ekondrashev we tried to fix that in #309, but failed, as I see...

@rultor try to merge again

@rultor try to merge again

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

@rultor try to merge again

@yegor256 Oops, I failed. You can see the full log here (spent 10min)

Results :

Failed tests:
  BkParallelTest.requestsAreParallel:127
Expected: <0L>
     but: was <1L>

Tests run: 226, Failures: 1, Errors: 0, Skipped: 4

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:58 min
[INFO] Finished at: 2015-06-05T17:09:10+00:00
[INFO] Final Memory: 25M/443M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project takes: There are test failures.
[ERROR]
[ERROR] Please refer to /home/r/repo/target/surefire-reports for the individual test results.
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project takes: There are test failures.

Please refer to /home/r/repo/target/surefire-reports for the individual test results.
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures.

Please refer to /home/r/repo/target/surefire-reports for the individual test results.
	at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:82)
	at org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:195)
	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:861)
	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	... 19 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

@yegor256 can we perhaps disable the test and reopen the #309?

@ekondrashev #309 is already closed and paid, no way to reopen it. But you can report a new ticket, explain the problem there and wait here until it's fixed

@yegor256 done, plz see #333
@davvd this PR merge is blocked by #333 hence original defect is also blocked, will comment on it also

@davvd we're waiting for #333 here

@yegor256 since the test is unstable, we could try to merge again I supposed. Maybe we get lucky this time :)

@rultor try to merge again

@rultor try to merge again

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

@rultor try to merge again

@yegor256 Done! FYI, the full log is here (took me 11min)

@davvd we're waiting for #333 here

@pinaf right, let's wait for #333

@davvd I believe there is no reason to wait for #333 now, since the PR was merged and initial ticket is closed already.

@elenavolokhova please, review this ticket for compliance with our QA rules

@rultor please deploy

@rultor please deploy

@davvd OK, I'll try to deploy now. You can check the progress here

@rultor please deploy

@davvd Done! FYI, the full log is here (took me 9min)

@davvd Quality is good here.

@davvd Quality is good here.

@elenavolokhova thanks for the review and a good remark

@pinaf since quality is good, 10 mins paid to @yegor256 (our architect), transaction 000-6a463b2b

@pinaf 10 mins was added to the account of @elenavolokhova (for QA review), in transaction 58704981; Thanks a lot, I just topped your account for 23 mins, transaction ID AP-29N57172GJ6916946, total time was 426 hours and 41 mins; extra minutes for review comments (c=8); +23 added to your rating, current score is: +7665


Add Chatterino to the Winget/Window's Store Repository

Microsoft has made an extension of the Windows Store's framework, presenting it into what is essentially their version of a Linux Package Manager. WinGet, said Package Manager, now past version 1.0 and getting a lot of interest.
So, here's the pitch: throw Chatterino up on the WinGet Package Manager, Microsoft tutorial available here: https://docs.microsoft.com/en-us/windows/package-manager/package/ , and let people download the latest stable release of Chatterino, or even the Beta releases and nightly update releases as well through separate packages, through the windows store and WinGet, vastly expanding the audience that comes across the program.
Only issue I may see with it is it's required, currently anyway, that you have a "Silent Install", ie no user input, for the application to be accepted. Thankfully Chatterino doesn't take up much room, so the biggest thing would be adding a script to auto-install the C++ updates and such from Microsoft if they're not already on the PC, rather than asking the user for input every time

 @ALazyMeme do you want to take that as well? Might tie in with the Chocolatey package

I believe there was something in here about this: https://github.com/Chatterino/chatterino2/issues/2849
Chocolatey had it easier as it supports dependencies. This isn't really something I want to do unless winget had support for it: https://github.com/microsoft/winget-cli/issues/163
Other people are willing to try, but I'm too lazy to make a script just to install the vcredists.

Added in https://github.com/microsoft/winget-pkgs/pull/127421

Any chance the updated build can be added?

Any chance the updated build can be added?

I opened https://github.com/Chatterino/chatterino2/pull/5365 to automatically add future releases to WinGet.


Inject trace_id attribute in loki log

Description
When exporting a log with default instrumentations there is no trace_id attributes. So we can't use loki's derived fields functionnality (https://grafana.com/docs/grafana/latest/datasources/loki/#configure-derived-fields) to make simple link between log and traces.
Was able to make something with session_id but there is a bug in derived fields functionnality where an arg is pass to undefined so it's not perfect
Proposed solution
Adding a trace_id attributes when sending log.
Context

@AMontagu  Just for clarification.
What do you referring to when talking about default instrumentations?

The ones contained in getWebInstrumentations
Or do you mean the TracingInstrumentation one can additionally add?

Cheers,
Marco

Hello @codecapitano
I looked a bit into it and I am confuse.
So I am actually talking for both. Any log (pushLog method of faro.api) should have the current trace_id to be able to map log with trace.
The main example here is when an Error is raised in the browser after a Fetch or XMLHTTPRequest this error produce a log and in this log one of the attributes should be the trace_id to correlate both.
But it is not send.
I started looking in the code and in the pushLog method there is trace key added to the item send by getTraceContext: https://github.com/grafana/faro-web-sdk/blob/main/packages/core/src/api/logs/initialize.ts#L41
And in this getTraceContext method we actually should have a context that contain a traceId and a spanId:
https://github.com/grafana/faro-web-sdk/blob/main/packages/core/src/api/traces/initialize.ts#L29
But my spanContext is undefined and I don't undestand wy.

@codecapitano is it done and working on the last version ?

Hi @AMontagu if web-tracing instrumentation is enabled it adds trace_id  / span_id if a trace context is available.
https://github.com/grafana/faro-web-sdk/blob/6de2e06ee87af72a251966854284491f307341fb/packages/core/src/api/logs/initialize.ts#L41-L42
Cheers,
Marco


[FLINK-27292][docs-zh] Translate the "Data Type Extraction" section of "Data Types" to Chinese

What is the purpose of the change
FLINK-27292
Translate the "Data Type Extraction" section of "Data Types" to Chinese.
Brief change log
Translate the "Data Type Extraction" section of "Data Types" to Chinese, the doc file is located in
'docs/content.zh/docs/dev/table/types.md'
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Hi @ChengkaiYang2022 , could you help to review this? thank you.

I finished the translation, and sorry that no one assigned this issue to me first.
I have asked for it, can @wuchong or @MartijnVisser assign this to me? thank you.

@jjiey could you a add picture of the part you translate?
Just like https://github.com/apache/flink/pull/19496#issuecomment-1115132533

@jjiey could you a add picture of the part you translate? Just like #19496 (comment)

@ChengkaiYang2022 fine. here is the link, and picture is as follows.

Thanks for @ChengkaiYang2022‘s review, I've finished the modification.


policy kl [old | new]

I believe the kl we want to record is KL[policy_old || policy_new]
Perhaps @natolambert can confirm?

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

For things like this, I think it's best to run a couple examples with and without the change. In theory, I think you can be right (@lvwerra probably knows).
I went back to the original repo and saw that TRL matches it.
https://github.com/openai/lm-human-preferences/blob/bd3775f200676e7c9ed438c50727e7452b1a52c1/lm_human_preferences/train_policy.py#L360

thanks @natolambert yes the approxkl is fine since its the square of the difference so order is not important. Its the policykl which is not correct i believe.

I wonder where that actually came from since it was not part of the original implementation 😂. True, if policykl should measure the KL-div of the current to the old policy then it's the wrong way round. Since it's only used for monitoring I am up to changing it unless there is a strong incentive to keep it that way.

yes in any case it's just for logging, it's not used to back-prop etc. I check other implementations e.g. ray, spinningup etc. and they have it as in this fix.


Add D Implementation

Prepared regular implementation https://github.com/jinyus/related_post_gen/pull/193
Please review and merge :)


StreamHandler Pipe to Process?

StreamHandler uses fopen which is great for logging to files, but what about logging to another process? For example:
$log->pushHandler(new StreamHandler('|/usr/bin/mylogger.py', Logger::DEBUG));

Is there a way to do this currently in Monolog?

Have you tried creating a FIFO (named pipe) and use the StreamHandler to write to it?

I want to use monolog to log write redis, there is an error, how can I solve?

@jackminh first of all you can report a new issue for things that don't have any connection with this one. And then if you have an error you might want to post the error, because otherwise we have no clue how to help.

Fixed by #720 (only in the upcoming 2.0)


Add support for getting username from keyring

Flit uses keyring.get_password() to load a password for authentication to the package index.
However, keyring also provides an API to get a username also, keyring.get_credential().
Twine already has support for this and will not prompt for a username if get_credential() returns a credential. However flit always prompts if the username is not set in .pypirc.
This is particularly useful where the username is not particularly meaningful and therefore should not be typed by the user - for example, Google Artifact Registry has a keyring plugin that returns a username of oauth2token where the OAuth token is the password.

Thanks, I think this makes sense. I also want to add support for per-project tokens, which might mean looking them up using the project name as part of the 'username'. So we might need to take some care over what order different possibilities are tried.

@takluyver This enhancement is probably required now, especially when using keyring with the Google keyring provider. There's really no way to authenticate without some fixes.
I was able to use twine to publish to Google Artifactory. Here's the pypirc.
[distutils]
index-servers =
    hi-int-prd-shared-applications

[hi-int-prd-shared-windows-applications]
repository = https://us-central1-python.pkg.dev/hi-internal-prod-b0da/hi-int-prd-shared-applications/

[global]
index-url = https://us-central1-python.pkg.dev/hi-something-9999/hi-int-prd-shared-applications/simple/

As you can see, twine does not expect username or password in the configuration.

And here's a link to the Google documentation on publishing python packages to Artifact Registry.
https://cloud.google.com/artifact-registry/docs/python/manage-packages


Use item data from each slot used to preserve NBT data.

A small change to preserve item NBT data when importing from a target inventory using a ME bridge.

Note that this bug may affect other storage devices like the RS interface.


Separation of vcs root and build root

The vcs root (repo) and build root (where setup.py is) may not be always the same. For example, apache arrow (https://github.com/apache/arrow) has setup.py  in <vcs_root>/python.
Could you add a variable like build_dir to asv.conf.json so that users can specify a relative build path from repo? (It could be . by default, but could be set to ./python for arrow.)

For now, I am using the way described in the arrow doc:
https://github.com/apache/arrow/blob/master/python/doc/Benchmarks.md
and it seems to work well.


ITK-MessageHeader-2 for ITK Wrapper sender

In the ITK wrapper the IKT-MessageHeader-2 has a sender element which is the Spine for the PDS events. A decision needs to be made if this should always be the spine or should be the originating organisation when the NEMS sends on the event messages received through the publish API.

Discussed seperatly


Could someone provide the supplementary material of this paper ? Unsupervised Monocular Depth Learning in Dynamic Scenes

I downloaded this paper but can't find the supplementary material.
Unsupervised Monocular Depth Learning in Dynamic Scenes https://arxiv.org/abs/2010.16404
Could someone provide it? Thanks !

There is a supplementary materials section of this version of the paper:
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/662284996d9111bef7ba49285e71ce62a5f2ecbd.pdf
Although I'm not sure it contains everything they reference in the arxiv version.

@jessedaniels Thank you ！

See "Ancillary files" of that arxiv page.

@uniqueness Thank you.  I followed your instructions and found the supplementary material, as well as some videos.


Improved measurement setup with taskset, removed crud from rust bench

Now all measurements are forcing the server to run on 4 cores exactly, and wrk is forced to use the other 4 cores. Naturally, if someone has less than 8 cores they should upgrade=)
Also rust example now does not waste time waiting for IO and does not have useless memory allocations. It is still 2x slower than go due to lack of proper evented IO (which is covered by axum).

Thank you for the improvements. Really, so many people have complained, maybe even looked at the code, but nothing ever came from it. So I am really grateful you dug into this!
Your proposed changes got me thinking:
I certainly don't mind isolating the server to 4 cores and wrk to 4 other cores. But for relative comparisons, I'd argue that all subjects under test are influenced by the same test setup. So, I am not sure whether it is really necessary for relative comparisons.
Then, I revisited the 4 threads topic. I recall why the rust code uses 4 threads only. Because the the zap code also uses 4 threads:
    zap.start(.{
        .threads = 4,
        .workers = 4,
    });

This got me thinking: why waste 4 processes for 4 threads. The IPC might slow things down. By experimentation, I figured out that the ideal number of worker processes seems to be: 2 for 4 threads.
    zap.start(.{
        .threads = 4,
        .workers = 2,
    });

With that I got the following results (3 runs):
Requests/sec: 686589.24
Transfer/sec:    104.11MB

Requests/sec: 658573.26
Transfer/sec:     99.86MB

Requests/sec: 681040.33
Transfer/sec:    103.27MB

Which averages out to:
avg. requests/sec: 675400.94
avg. transfer/sec:    102.41MB

compared to 4 workers:
avg. requests/sec: 649692.13
avg. transfer/sec:    98.52MB

Which is significant.
Now, the question to me is: is it fair to give the rust example 128 threads when the zap example gets only 4?
BTW my tests from above weren't yet made with the 4 / 4 core split that you suggest.

Thank you for the improvements. Really, so many people have complained, maybe even looked at the code, but nothing ever came from it. So I am really grateful you dug into this!
Your proposed changes got me thinking:
I certainly don't mind isolating the server to 4 cores and wrk to 4 other cores. But for relative comparisons, I'd argue that all subjects under test are influenced by the same test setup. So, I am not sure whether it is really necessary for relative comparisons.
Then, I revisited the 4 threads topic. I recall why the rust code uses 4 threads only. Because the the zap code also uses 4 threads:
    zap.start(.{
        .threads = 4,
        .workers = 4,
    });

This got me thinking: why waste 4 processes for 4 threads. The IPC might slow things down. By experimentation, I figured out that the ideal number of worker processes seems to be: 2 for 4 threads.
    zap.start(.{
        .threads = 4,
        .workers = 2,
    });

With that I got the following results (3 runs):
Requests/sec: 686589.24
Transfer/sec:    104.11MB

Requests/sec: 658573.26
Transfer/sec:     99.86MB

Requests/sec: 681040.33
Transfer/sec:    103.27MB

Which averages out to:
avg. requests/sec: 675400.94
avg. transfer/sec:    102.41MB

compared to 4 workers:
avg. requests/sec: 649692.13
avg. transfer/sec:    98.52MB

Which is significant.
Now, the question to me is: is it fair to give the rust example 128 threads when the zap example gets only 4?
BTW my tests from above weren't yet made with the 4 / 4 core split that you suggest.

Update: You've convinced me that the taskset stuff is good because it creates even more impressive numbers :smile:.
However, I just ran the new, updated rust example and still get no performance increase. Here are some exemplary runs on my machine:
./wrk/measure.sh zig
Listening on <IP_ADDRESS>:3000
========================================================================
                          zig
========================================================================
Running 10s test @ http://<IP_ADDRESS>:3000
  4 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   588.74us  423.55us  17.88ms   92.34%
    Req/Sec   175.71k    26.96k  216.79k    52.75%
  Latency Distribution
     50%  487.00us
     75%  674.00us
     90%    0.93ms
     99%    2.12ms
  6991199 requests in 10.02s, 1.04GB read
Requests/sec: 698047.77
Transfer/sec:    105.85MB

contrib_zap on  master via ↯ v0.11.0 via  impure (nix-shell) took 11s
➜
./wrk/measure.sh rust
    Finished release [optimized] target(s) in 0.03s
========================================================================
                          rust
========================================================================
Running 10s test @ http://<IP_ADDRESS>:7878
  4 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   624.20us    1.49ms 208.31ms   99.90%
    Req/Sec    33.01k     5.21k   39.64k    64.25%
  Latency Distribution
     50%  579.00us
     75%  738.00us
     90%    0.93ms
     99%    1.38ms
  1313715 requests in 10.02s, 68.91MB read
  Socket errors: connect 0, read 1313668, write 0, timeout 0
Requests/sec: 131114.37
Transfer/sec:      6.88MB

contrib_zap on  master via ↯ v0.11.0 via  impure (nix-shell) took 11s
➜ ./wrk/measure.sh go
listening on <IP_ADDRESS>:8090
========================================================================
                          go
========================================================================
Running 10s test @ http://<IP_ADDRESS>:8090/hello
  4 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.18ms  810.81us  13.95ms   75.24%
    Req/Sec    89.86k     1.04k   92.66k    73.25%
  Latency Distribution
     50%    1.09ms
     75%    1.54ms
     90%    2.12ms
     99%    4.18ms
  3577111 requests in 10.02s, 457.13MB read
Requests/sec: 356961.73
Transfer/sec:     45.62MB

In fact, it seems to have gotten a bit slower. Here is an exemplary run of the "old" code:
➜ ./wrk/measure.sh rust
    Finished release [optimized] target(s) in 0.03s
========================================================================
                          rust
========================================================================
Running 10s test @ http://<IP_ADDRESS>:7878
  4 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.26ms  625.30us  14.34ms   64.06%
    Req/Sec    34.14k     2.63k   39.02k    78.75%
  Latency Distribution
     50%    1.38ms
     75%    1.69ms
     90%    1.97ms
     99%    2.54ms
  1359392 requests in 10.01s, 71.30MB read
  Socket errors: connect 0, read 1359370, write 0, timeout 0
Requests/sec: 135751.05
Transfer/sec:      7.12MB

I repeated the rust runs a few times and the examples above are representative on my machine.
Speaking of my (testing) machine:
➜ neofetch
          ▗▄▄▄       ▗▄▄▄▄    ▄▄▄▖            rs@ryzen
          ▜███▙       ▜███▙  ▟███▛            --------
           ▜███▙       ▜███▙▟███▛             OS: NixOS 23.05.997.ddf4688dc7a (Stoat) x86_64
            ▜███▙       ▜██████▛              Host: Micro-Star International Co., Ltd. B550-A PRO (MS-7C56)
     ▟█████████████████▙ ▜████▛     ▟▙        Kernel: 6.3.7
    ▟███████████████████▙ ▜███▙    ▟██▙       Uptime: 14 days, 17 hours, 11 mins
           ▄▄▄▄▖           ▜███▙  ▟███▛       Packages: 2094 (nix-system), 1356 (nix-user), 7 (flatpak)
          ▟███▛             ▜██▛ ▟███▛        Shell: bash 5.2.15
         ▟███▛               ▜▛ ▟███▛         Resolution: 3840x2160
▟███████████▛                  ▟██████████▙   DE: none+i3
▜██████████▛                  ▟███████████▛   WM: i3
      ▟███▛ ▟▙               ▟███▛            Terminal: tmux
     ▟███▛ ▟██▙             ▟███▛             CPU: AMD Ryzen 5 5600X (12) @ 3.700GHz
    ▟███▛  ▜███▙           ▝▀▀▀▀              GPU: AMD ATI Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT
    ▜██▛    ▜███▙ ▜██████████████████▛        Memory: 4222MiB / 32028MiB
     ▜▛     ▟████▙ ▜████████████████▛
           ▟██████▙       ▜███▙
          ▟███▛▜███▙       ▜███▙
         ▟███▛  ▜███▙       ▜███▙
         ▝▀▀▀    ▀▀▀▀▘       ▀▀▀▘

My AMD CPU shows up as 12 cores in htop.
I am willing to merge this, since the measure.sh improvements are great!
But the rust-example performance differences, for some strange reason, are not so great, and on top of it: negative. I will experiment with the thread count for a moment and give an update in a few minutes.

Update: I tried 8, 12, 16, 32, 64 threads and did not get really different numbers out of it: most were ca. 131k req/s.
What stood out was 32 threads, where I got > 131k rather consistently:
➜ ./wrk/measure.sh rust
    Finished release [optimized] target(s) in 0.03s
========================================================================
                          rust
========================================================================
Running 10s test @ http://<IP_ADDRESS>:7878
  4 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     0.92ms    1.02ms 203.00ms   96.12%
    Req/Sec    33.42k     4.73k   39.67k    54.75%
  Latency Distribution
     50%  801.00us
     75%    1.36ms
     90%    1.71ms
     99%    2.20ms
  1330109 requests in 10.02s, 69.77MB read
  Socket errors: connect 0, read 1330101, write 0, timeout 0
Requests/sec: 132749.58
Transfer/sec:      6.96MB

contrib_zap on  master [!] via ↯ v0.11.0 via  impure (nix-shell) took 11s
➜ ./wrk/measure.sh rust
    Finished release [optimized] target(s) in 0.03s
========================================================================
                          rust
========================================================================
Running 10s test @ http://<IP_ADDRESS>:7878
  4 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     0.93ms    1.03ms 203.78ms   96.54%
    Req/Sec    33.51k     4.88k   39.83k    51.75%
  Latency Distribution
     50%  824.00us
     75%    1.37ms
     90%    1.72ms
     99%    2.20ms
  1333909 requests in 10.02s, 69.97MB read
  Socket errors: connect 0, read 1333871, write 0, timeout 0
Requests/sec: 133136.87
Transfer/sec:      6.98MB

contrib_zap on  master [!] via ↯ v0.11.0 via  impure (nix-shell) took 11s
contrib_zap on  master [!] via ↯ v0.11.0 via  impure (nix-shell) took 11s
➜ ./wrk/measure.sh rust
    Finished release [optimized] target(s) in 0.03s
========================================================================
                          rust
========================================================================
Running 10s test @ http://<IP_ADDRESS>:7878
  4 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     0.92ms  606.17us  16.93ms   66.11%
    Req/Sec    33.28k     4.71k   39.83k    63.25%
  Latency Distribution
     50%  804.00us
     75%    1.37ms
     90%    1.72ms
     99%    2.24ms
  1325189 requests in 10.03s, 69.51MB read
  Socket errors: connect 0, read 1325154, write 0, timeout 0
Requests/sec: 132167.69
Transfer/sec:      6.93MB

contrib_zap on  master [!] via ↯ v0.11.0 via  impure (nix-shell) took 11s
➜

Hang on. There's another difference: when I tested the old code, I also tested with the old measure.sh which did not limit the rust server to 4 threads.
With the new measure.sh and the old rust code, I get 132k, 136k, 134k, 138k req/s.
I am curious, how does the new rust code compare to the old one on your machine and what kind of machine is it?
Some more info:
$ rustc --version
rustc 1.69.0 (84c898d65 2023-04-16) (built from a source tarball)
$ cargo version
cargo 1.69.0

Ok I think the most important bit is that you have to always isolate the load generation from server to the best of your ability. So taskset should stay =)
As for number of threads, this just constraints how many things you could run in parallel, not how much you actually get (the latter is achieved with taskset).
zap (and most other modern web frameworks) use event based IO, and as a result they can actually serve multiple connections with one thread, so they only need as many threads as you have cores. The silly rust code uses blocking IO, and as a result needs more threads (though only 4 of them will be running at any given point in time).
My machine is a ryzen 5, though relative numbers should translate well across machines. I actually could not compile zap due to some zig errors, so I was comparing with go and axum (which is about as fast as rust is able to go anyway).
I've also eaten the brains of the folks in the rust community about why axum is so fast, and most people conclude it is some sort of dark magic that is not given to mere mortals.

Well put. Thanks for your clarifications and explanations.
Agree, the taskset should stay.
I used to do select in the nineties, so IMHO old web / networking code is a kind of role-model to modern event-based I/O, which often combine events & threads or (async) "coroutines".
I agree that the silly rust code using blocking I/O reaches its performance limits very quickly, as only ever 4 connections can be served concurrently (under taskset constraints).
Interesting that you are on a Ryzen 5, too! 😊
Regarding compiling zap: I have pinned zap to the 0.11.0 ( = latest) release of zig recently. So it might not work with zig master anymore.
My question to you now is: should I merge the entire PR?
Can you compare the old rust code with your new rust code using (your adapted) measure.sh?
I am wondering: if the old (by-the-book) variant does unnecessary memory allocations and your clean version does not, why is the old version slightly faster on my machine?
Seems like a darker kind of dark magic to me 😊.
Alternative: I could provide both rust implementations. Then automate the perf tests so it's easy for anyone to replicate and see which one performs best.
Please let me know how you'd like me to proceed with this PR.

Update: I added your rust example as "rust-clean" and renamed the other one to "rust-bythebook".
I created a wrk/measure_all.sh convenience script that runs all perf tests 3 times.
Also, wrk/graph.py generates the performance graphs: req/sec, xfer/sec, based on the mean of the 3 runs each.
The nix flake provides all dependencies. For python, you need matplotlib for generating the graphs (and sanic if you want to test it).
I will run all this on my test machine when I return home. On my work laptop, I get these results which I don't want to put in the README because it looks terribly based :facepalm: :

Maybe if you can hack measure_all.sh to just run the 2 rust versions, then run python ./wrk/graph.py, you can check which of the two is faster on your machine. I am still curious.

Okay, with some help from the community, here are the reasons for poor perf (in order of importance)

no keepalive support - so the client had to reopen connection for every request, while other implementations are reusing connections (at least they should, and wrk expects them to)
Having just 4 threads doing blocking IO resulted in poor utilization of the CPU due to stalls.
mutex of channel was a bad idea =) Having a bunch of channels is way better.
passing trait objects where a function pointer is sufficient creates some overheads (small as they are) in a sense that trait objects require memory allocation, which needs to be synced across threads.

Just checking. Is it ripe for merging?

Awesome contrib @alexpyattaev , :clap:
My Setup

CPU: Ryzen 7 5700G
RAM: 12GiB
DISK: SSD Kingston

Note: my OS (arch-linux) doesn't have python-sanic and dotnet installed.
Running test

@kassane there is something seriously strange going on on your machine. I just cannot wrap my head around the simplistic, blocking rust-bythebook example outperforming axum. Rust and performance will forever be a mystery to me. People argue theoretically why their rust implementation is bound to be fast (because of x, y, z) but when you put it to the test, theory and reality often don't like to agree. Similar thing can be said about cpp-beast. It claims to be async and a beast, yet its performance seems to be below what I would expect from a "fast" C++ application. I more and more come to the conclusion that perf tests are a trap. How is it possible that "shitty" rust outperforms axum. My mind is blown!

@kassane have you used @alexpyattaev 's latest patch btw? I haven't because I want to get his "finished, ready for merging" signal first.
Just wondering... By my logic, that one is supposed to be faster than the bythebook example.
Why are all rust implementations performing similarly fast on your machine when their implementations are so different? This could mean they all hit the same limit of your system.
Can you also share your lscpu output?

@kassane have you used @alexpyattaev 's latest patch btw?

yes! replacing rust implementation only.

Can you also share your lscpu output?

$>lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  16
  On-line CPU(s) list:   0-15
Vendor ID:               AuthenticAMD
  Model name:            AMD Ryzen 7 5700G with Radeon Graphics
    CPU family:          25
    Model:               80
    Thread(s) per core:  2
    Core(s) per socket:  8
    Socket(s):           1
    Stepping:            0
    Frequency boost:     enabled
    CPU(s) scaling MHz:  49%
    CPU max MHz:         4672.0698
    CPU min MHz:         1400.0000
    BogoMIPS:            7588.80
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_
                         opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 f
                         ma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misa
                         lignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_
                         pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb
                         sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoi
                         nvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsa
                         ve_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm
Virtualization features:
  Virtualization:        AMD-V
Caches (sum of all):
  L1d:                   256 KiB (8 instances)
  L1i:                   256 KiB (8 instances)
  L2:                    4 MiB (8 instances)
  L3:                    16 MiB (1 instance)
NUMA:
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-15
Vulnerabilities:
  Gather data sampling:  Not affected
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Retbleed:              Not affected
  Spec rstack overflow:  Mitigation; safe RET, no microcode
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                 Not affected
  Tsx async abort:       Not affected

Welcome to the Ryzen club btw 😁.
@alexpyattaev sorry to be such a pain but: do you consider the PR ready for merging? I desperately want to try it out, but better wait until it is finished.

Hi, yes, as far as I can tell it is all good to go.

Why are all rust implementations performing similarly fast on your machine when their implementations are so different? This could mean they all hit the same limit of your system.

The performance of these impls depends a lot on how the memory hierarchy works in your CPU. The one with thread pool pre-made requires way less memory bandwidth, so it will perform somewhat better on a low-end CPU. On a high-end CPU it should all be about same.

So, I wanted to keep the by-the-book example for reference. In my eyes, we now have 4 rust implementations:

by-the-book (as in zap's repo now)
improved by-the-book (bythebook modified by you)
"clean" (your new implementation)
axum

I would take your branch's bythebook and integrate it into the zap repo as 'bythebook-improved', use your clean as 'clean', and keep the old 'bythebook'.
Would you agree? Or am I getting sth terribly wrong here?

Uh... yes... sorry for confusion. I should have given it a better name=) The idea was that

"clean" is the "clean code" sort of implementation. Silly, inefficient, straightforward.
by the book would be a thread pool implementation, inspired by the rust book. The literal "as in the book solution" is not suitable for this comparison (as it does not have keepalive and has terrible thread sync arrangements). The only thing that would illustrate to zap users is that it is indeed possible to write terrible rust =) I'll be making a fix to the actual rust book once I have some time spare.

OK, thanks for clarifying. I will go ahead as outlined above if you don't mind, with the result being the 4 rust versions.
We could argue to leave the "classic bythebook" out of `measure_all.sh", and only keep the clean, and the bythebook-improved (as I would call it) versions, i.e. your current versions, in there.

It's entirely up to you which code to leave in vs out, my hope is simply to make sure that people using these benchmarks do not get misleading information.

I think I will have to put in a legend under or on top of the graphs explaining the shortcomings and inapplicability of the original book version which should be underlined by the bythebook-improved version performing much better.
See my updated blazingly-fast.md: I don't like adding more benchmarks. The more there are, the more people get misled. And then, so set things straight, even more benchmarks need to be added which will trigger even more reactions in the form of slightly better implementations, etc. Soon we'd have multiple versions for all programming languages and even frameworks. I probably would make an exception for one good C++ implementation though, as I fear, cpp-beast is not the ideal candidate for representing C++. It was @kassane 's idea and I had thought with such a name it would be an absolute beast so I approved before measuring.

OK, so I have an idea: we put all the details into the blazingly-fast document - and keep the one in the readme simplified (with a link to the other document)

@alexpyattaev I cannot thank you enough. The endless shitstorms I received because of the rust benchmark should be a part of history. :smile: :+1:
You have also done the rust community a huge service. Many have tried, but only you (and your friends) succeeded, diving into the details deep enough and coming up with really favorable results for rust.
Thanks again, I will close this PR now, it has all been merged, as you can see in the blazingly-fast (details) and README.
Thanks again for your valuable contributions!!!!! :tada:

I'm happy to help. Thanks for braving the shitstorm and actually getting to the truth=) Rust fans can be quite toxic at times, there is way too much hype and drama. Be prepared though, zig will have its fair share at some point too.

I sure will ping you!
So far, the zig community (... as if all users of languages were in big, respective communities - but for a lack of a better word, I, too use it) has been small enough I suppose. Also, the maintainers are doing a brilliant job of leading by positive example. I wish it will stay this cozy. But once zig adoption becomes massive, no doubt will it also attract lower character people, toxic ones, and radical fans riding on the hype wave. I see potential for an ongoing pun-like competition between rust and zig devs to get out of hands sometimes, creating drama. I also have my own vague, not thought-through, theories about the need to feel "safe" (as opposed to: mere valuing safety) in one's programming language and certain personality traits. Could be totally wrong there but it surely makes for a good conspiracy theory 😂.


Python: No module named 'semantic_kernel.skill_definition'

Describe the bug
No module named 'semantic_kernel.skill_definition' when importing sk_function,sk_function_context_parameter,
To Reproduce
In this article https://learn.microsoft.com/en-us/semantic-kernel/agents/plugins/using-the-kernelfunction-decorator?tabs=python it demonstrate a way of creating a native kernel function.
When doing as per said
from semantic_kernel.skill_definition import (
sk_function,
sk_function_context_parameter,
)
It shows that 'No module named 'semantic_kernel.skill_definition''
Expected behavior
Successfully import the module.
Screenshots

Platform

OS: Windows
IDE: VS Code
Language: Python 3.10.13
Source: semantic-kernel-0.4.7.dev0

Got exact same issue

The last updated notebook doesn't work for me. I changed the way of installing the dependency in the notebook:
!python -m pip install semantic-kernel==0.9.5b1
by
%pip install --quiet semantic-kernel==0.9.5b1

@XiangkunFang, @BSlap we've been making a lot of breaking changes lately as we move towards SK Python v1.0. Because we've been moving so quickly, our learn docs are out of sync with our code. We're tracking an item related to this. Can you please use the SK Python notebooks or kernel examples? They should be more up to date and reflective of the code that is in the repo.
Per previous PR's, the sk prefix was removed from all names/files. sk_function -> kernel_function. Skills have also been updated to Plugins.
This example notebook would be useful to reference.

The link corresponding to example notebook is giving 404 error.

example notebook

We've restructured our samples. Here is the link: https://github.com/microsoft/semantic-kernel/blob/main/python/samples/getting_started/08-native-function-inline.ipynb


amplify add codegen failed with Downloading schema failed / Internal server error.

Amplify CLI Version
10.5.2
Question
When we are trying to add amplify codegen (Using this command amplify add codegen --apiId **************) in a amplify project that we pulled using this command amplify pull --appId ************** --envName testapp it is getting failed with this error.

Hey @rahulnainwal107 :wave: thanks for raising this! As we begin to look at this in more depth I wanted to clarify something. Is the API added with amplify add codegen --apiId xxx the same API that is attached to the Amplify project with amplify pull

Hi @josefaidt, thanks for response. I am not clear with your question but if you are talking about apiId then yes we are using  different appId. For amplify pull --appId ************** --envName testapp we used amplify appId but for amplify add codegen --apiId ************** appsync appId.

Hi @rahulnainwal107 👋, Apologies for the delay. Could you please execute this command 'amplify add codegen --appId xxx --debug' and share us the logs?

Hi @rahulnainwal107  👋, We are closing this issue as we have not received any response from you. However, if you are still facing the same issue and require our assistance, please don't hesitate to leave a comment and provide us with the information our team had previously asked for. This way, we can reopen the issue and provide you with better assistance.
Thank you!


tests: enable allegedly flaky ingress cache test

Signed-off-by: Kuat Yessenov<EMAIL_ADDRESS>

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: kyessenov
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/OWNERS [kyessenov]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@hklai per our discussion, let's enable it back. It passed from the first try, and I failed to reproduce it after repeatedly running it.

There is another skipped test there. I'll do the same thing to the other
test in a few days, and I can clean up the comment then.
On Wed, Jun 20, 2018, 3:03 PM Andy Lai<EMAIL_ADDRESS>wrote:

@hklai commented on this pull request.
In tests/e2e/tests/mixer/mixer_test.go
https://github.com/istio/istio/pull/6444#discussion_r196956612:

@@ -729,7 +729,7 @@ func testDenials(t *testing.T, rule string) {

// TestIngressCheckCache tests that check cache works in Ingress.
func TestIngressCheckCache(t *testing.T) {

t.Skip("https://github.com/istio/istio/issues/6309")

//t.Skip("https://github.com/istio/istio/issues/6309")

Just remove the whole line, assuming this test is going to stay.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/6444#pullrequestreview-130605402,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJGIxockNU8MrUjZgDUlKxzp_hLSBxrCks5t-sadgaJpZM4Uv9jm
.

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: kyessenov, rshriram
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/OWNERS [kyessenov,rshriram]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

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

Test name
Commit
Details
Rerun command

prow/e2e-dashboard.sh
ab584004dc46d0446ac07203b93cd46147a2e8b6
link
/test e2e-dashboard

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.


Update of SIG Interoperability Meeting Invite with Zoom Link

The meeting invitation for SIG Interoperability has been updated with the agenda/meeting notes on HackMD which is great.
However, the updated invitation does not contain the Zoom meeting information any longer.
Could we get the invitation updated and the Zoom link below is set as the location for the meeting please?
https://zoom.us/j/827082528

The invite has been updated with the Zoom link. Thanks a lot for the help. Closing the issue.


Waypoints aren't in their correct places on initial load

I'm not sure if this can be related to #47, but I'm facing this weird scenario when CSS styles aren't taken into account on initial load. I'm not using inline styles, maybe that's why.
For example, I've set up a waypoint after each item in a list. But when I scroll down just barely, it seems to pass the first couple of waypoints. However, I'm actually nowhere near the 2nd waypoint! But after that initial scroll, everything seems to work properly. My guess is that the CSS isn't taken into account from the beginning.
Is there a simple fix? I'm current checking the page offset using window.pageYOffset, but it seems out of place.

Hi @bkgunby, sorry for the late response.
What does your list look like? A common gotcha when using waypoints are images that don't have a static height on load. Also, if you are using floats, there's a chance the waypoint is positioned at an unexpected place.

I'm using flexbox to align the images vertically, so you're probably right and possibly out of this package's scope. Closing this for now as I do have a hacky solution mentioned in my OP, but it's not as clean as I want it to be.

Thanks for providing that bit of context. If you can think of ways we can detect this scenario and show a warning of some sort, let us know!


Dotnet tool restore search wrong paths on ubuntu

Dotnet tool restore search windows pathes on Ubuntu
General
When trying to restore a local dotnet tool from .config\dotnet-tools.json on an ubuntu debian 16.04, by running the command:
dotnet.exe tool restore
the dotnet tool will search for a dotnet-tools.json in the following directories, instead of relative pathes from your current position to the root folder.
Cannot find any manifests file. Searched:
C:\WINDOWS\system32.config\dotnet-tools.json
C:\WINDOWS\system32\dotnet-tools.json
C:\WINDOWS.config\dotnet-tools.json
C:\WINDOWS\dotnet-tools.json
C:.config\dotnet-tools.json
C:\dotnet-tools.json
No tools were restored.

@livarcocc @KathleenDollard

@wli3

Filed https://github.com/dotnet/corefx/issues/36003
And apparently you can run an exe in WSL (!!!)

@leecow Yes i have only tested on a windows subsystem, but other console applications using System.IO.Path to handle directories, does not seem to have the same problem

Closing this issue in favor of dotnet/corefx#36003


Adds support for shorthand force-push syntax

Git supports a short-hand syntax for force-pushing a branch to a remote by including the "+" modifier before the branch name. However when doing so, Posh-git was no longer able to auto-complete the branch name as it did not understand this syntax.  This PR adds that support.
Closes #173

Any chance of this making it in @dahlbyk?

So sorry for the delay in looking at this, @dan-turner. I appreciate you looping back around to bump it, as this is definitely something we should support.