[tests-only][full-ci]Reuse code from code for favorites.feature in ocis

This PR of using the resource (code) from core as much as possible since there has been a duplication of code that already exists in core. A method to set the space id sets the space id of (Space) not implemented on core is added to make it work. This is an example with favorite.feature of ocis. A few adjustment has been done in core for this to works. Can be seen in this Core PR https://github.com/owncloud/core/pull/40328.
And This PR depends on:
https://github.com/owncloud/core/pull/40328

LGTM.

@SagarGi are you going to make a different pr for the remaining duplication? Their is remaining code to refactor sendPutRequestToUrl sendCreateFolderRequest() sendPutRequestToUrl . I think we can directly use core code for HTTP requests. Do we need this function in ocis?

We need to only refactor if we are implementing and duplicating the core code. I don't think we need to refactor those.

@SagarGi are you going to do adjustment for

@SagarGi are you going to make a different pr for the remaining duplication? Their is remaining code to refactor sendPutRequestToUrl sendCreateFolderRequest() sendPutRequestToUrl . I think we can directly use core code for HTTP requests. Do we need this function in ocis?

@amrita-shrestha We need to only refactor if we are implementing and duplicating the core code. I don't think we need to refactor those. I will be creating different issue if this PR is merge. This is a Sample PR for it only.

@SagarGi If you are going to create an issue for refactoring existing duplicate code as you told then that is nice. Otherwise, if we left other existing duplicated code like that then I think there will be no consistency, and newcomers/others will be confused.

@SagarGi are you going to do adjustment for

@SagarGi are you going to make a different pr for the remaining duplication? Their is remaining code to refactor sendPutRequestToUrl sendCreateFolderRequest() sendPutRequestToUrl . I think we can directly use core code for HTTP requests. Do we need this function in ocis?

@amrita-shrestha We need to only refactor if we are implementing and duplicating the core code. I don't think we need to refactor those. I will be creating different issue if this PR is merge. This is a Sample PR for it only.

@SagarGi If you are going to create an issue for refactoring existing duplicate code as you told then that is nice. Otherwise, if we left other existing duplicated code like that then I think there will be no consistency, and newcomers/others will be confused.

@amrita-shrestha Yes i will be creating once this PR gets merged. We will be clearing duplication code where we have added during shifting (/Shares) related issue.

Note: this gets the core commit id up-to-date - issue https://github.com/owncloud/QA/issues/763


Sidecar crd has no effect on ingress gateway

sidecar config is
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: sdkng-sdksvc
  namespace: mid
spec:
  workloadSelector:
    labels:
      app: istio-ingressgateway
  egress:
    - hosts:
      - "mm/abc.mm.svc.cluster.local"
  outboundTrafficPolicy:
    mode: ALLOW_ANY

This is working as intended, Sidecar impacts sidecar only not gateway

ths Looking forward to the release of this feature !

@howardjohn is there any intent to support this future releases? Without a Sidecar configuration, istio-proxy containers will not scale well with mesh size. Which pretty much renders Istio gateways unfit for any usage in a sizable mesh.

Not in this exact form, but in https://github.com/istio/istio/issues/29131. tl;dr only send clusters referenced in VirtualServices


Ref conflicts with Global components: Invalid vnode type when creating vnode: .

Version
3.2.31
Reproduction link
stackblitz.com
Steps to reproduce
I have created a global component named QRadio as you can see in main.js.
In App.vue, I use that component but I am also trying to create a ref to pass a reactive value to that component.
It seems that I can't use qRadio as a ref name because it somehow conflicts with the Global component.
What is expected?
The name of the ref should not conflict with the name of the global component
What is actually happening?
I get an error: Invalid vnode type when creating vnode: .

If I change the name qRadio of the ref then everything works

@LinusBorg thanks for taking the time to look at this.
First, I don't know why you are complicating stuff by putting components option and Options API. Also, your code doesn't make sense. How can you put ref in the components?
export default {
  components: {
    qRadio: ref('')
  }
}

As per the other example, why did you put ref inside the data? Properties get reactive by default there. I have experimented with putting ref and reactive inside data() but I've seen that this is a bad practice. Am I wrong?
export default {
  data: () => ({
    qRadio: ref('')
  })
}

Anyway, I can't believe how the current behavior is made by design. For others who take a look into this, let me show the code I tried:
<script setup>
import { ref } from 'vue';

const qRadio = ref('');
</script>

<template>
  <qRadio />
</template>

From the snippet above, <qRadio /> is a global component. So far so good.
Now I am creating a variable qRadio which is a ref with the intention to hold a value.
Why is by design that qRadio should interfere with QRadio global component?
To give it some context, in my original code I have a bottomSheet ref variable which tries to be used in a component named BottomSheet: <BottomSheet v-model="bottomSheet" />. I spent a good amount of time trying to figure out what is wrong and I finally found that variable naming interferes with global component naming.
So if you think that's not a bug but it's the intended behavior, I am expecting to get a warning at least so I know what I did wrong.

Probably my personal opinion doesn't count so much but in case it does, here are some bullet points:

Don't you think that an app can have many global components that can clash with ref variables?
Shouldn't this behavior get documented (couldn't find it in the docs)?
Since this is made by design. Don't you think devs won't expect that behavior? I don't know about the others but if this was in an RFC, I would not vote for this behavior because really, it doesn't make sense to me.
Speaking of RFCs is this behavior mentioned in any of them?

Please don't take my arguments against this "intended behavior by design" as negative. I am politely trying to state my thoughts and I respect every decision taken from Vue team. Thank you

First, I don't know why you are complicating stuff by putting components option and Options API. Also, your code doesn't make sense. How can you put ref in the components?

I see that I didn't make myself clear, sorry for that. So, let's restart and ignore my previous, confusing examples for a second.
I was trying to demonstrate that

in options API, you can override a globally registered component with a locally registered one.
in script setup, you don't register components, any top-level variable can be used as a component
so in script setup, a variable can override a globally registered component the same way that in options API, a locally registered one can.

Components are defined with variables
Typically, you see this in the common examples:
<script setup>
import {  from 'vue';
import MyComponent from 'vue'
</script>

<template>
  <MyComonent />
</template>

but you technically, can also do this:
<script setup>
import {  from 'vue';
import MyComponent from 'vue'
const qRadio = MyComponent
</script>

<template>
  <qRadio />
</template>

or this:
<script setup>
import { h } from 'vue';

// locally defined functional component just as a quick demo.
const qRadio = () => h('h1', 'I replaced qRadio!')
</script>

<template>
  <qRadio />
</template>

..which would override the globally registered <qRadio> component with MyComponent. Understand that I'm not saying this is a common thing to do, it's just a side effect of how you use components in script setup: any top level variable that matches a component name in the template will be used as the component.
Now, you might think: "I didn't define a component, I declared a ref! Surely Vue must warn me that I'm using something that can't be a component in place of a component!".
Well, it does, at runtime, with the error you are seeing.
Of course it would be better to have a more use case specific error message during compilation, but that would require that the compiler practically evaluates your code, because it would have to i.e. understand the difference between this:
const qRadio = ref('') // this is not a component, so we should warn during compilation, right?

qRadio.value = () => h('div', 'This is a functional component') // oh, now it *is* a component. should we no longer warn?`how do we detect this reliably?

So, in essence, we can't really warn about this reliably during compilation because we can't infer (with reasonably effort) wether or not a variable defined in script setup actually contains a component.
So, we have two choices, conceptually:

always prefer use a locally defined variable as a component in the template if they match by name, alllowing/riksing the override of globally registered components
never allow any locally defined variable to be used as a component when a global component of the same name exists, which would make it impossible to locally replace a component. It would also mean a (likely very minimal) performance impact as we can't optimize for the local variable in the render function's closure, instead we always have to check the global component register as well.

You would likely argue for 2. Which is a fine standpoint to have, but prefering 2. doesn't make 1. an invalid way of working, and thus not a bug. Changing Vue's behavior from 1. to 2. would be a breaking change, which requires a major release.

@LinusBorg thank you for the detailed explanation.
While I know why technically this fails and your explanation gives me a better understanding, I still think that this is a bug or at least should get improved. Sorry, I might be the only one who thinks that.
If the dev has a component imported locally, I don't think he/she will run into that issue because even JS won't let you declare the same variable twice. But when the component is globally registered, it's easy to fall into that issue.
Saying that it's not technically possible to understand if the variable is a ref or a component is a valid reason and I can accept that. In my limited knowledge of the internal code of Vue I believe that there must be a way to inspect the type of the variable and see if it's a ref but if you say it's not, then you are most probably right.
Since this is a rare issue, as you say, it should not get too much attention and probably get closed, but I believe an improvement should be made to better warn the user about this issue and/or add something to the docs about it. It can really take time to understand what the issue is and I guess I was lucky to understand that it was a naming issue because my component was a global one and didn't need import.

its not rare, you just need to be aware, that when you use <script setup>
you get all the magic  that comes with it.
if you want to use confusing names for components and variables, you can do that
just make sure they are not case conflicting when vue try to resolve  them.
This will not conflict
const qRadio = ref('');

  <QRadio />

haven't checked the docs, but resolution logic should be something that is documented.

if you want to use confusing names for components and variables, you can do that

@lidlanca I am not using confusing names. If you have read my comments, I said that in my original code I have a global component named BottomSheet and I have a variable bottomSheet which is a ref. And that's when I got the error.
After I figured out that the issue was the ref and global component naming, I tried to reproduce the issue in a simple way using another global component.
In my project I use Quasar and all components start with q- so used QRadio component with a qRadio ref and I saw that indeed the issue is due to the naming.

Personally, I don't have a problem living with that "limitation"/"behavior" but I thought it would be helpful to open an issue. If anyone runs into this, at least there is an issue about it.

its not rare

@LinusBorg said:

"is the first time in my almost daily interaction with users that this came up as an issue"

so it seems like a rare case this can happen.

when I said confusing I meant  visually conflicting/similar.
for example names that are just slightly different  (ex capital letter)
which is especially a problem where template have case insensitivity and more hidden logic.
BottomSheet
bottomSheet
HelloWorld
helloWorld
qButton
QButton
related
https://github.com/vuejs/core/issues/5285

Closing as this is working as intended as it's also the first line in docs: https://vuejs.org/api/sfc-script-setup.html#using-components

Values in the scope of


query: prometheus.url not used for remote read

Thanos, Prometheus and Golang version used

thanos --version
thanos, version 0.1.0-rc.2 (branch: master, revision: d068d53741b93e7b4be3f174fddacd44b786ca7d)
  build user:       root@thanos
  build date:       20180815-13:36:50
  go version:       go1.10

What happened
I'm running Prometheus using a URL prefix (/prometheus/). Because of this I started sidecar with the following option: --prometheus.url http://localhost:9090/prometheus. This works fine for requests the sidecar process makes itself. However, the Thanos query process doesn't seem to use this option. It does use the correct domain and port, but the URL prefix seems to be ignored as I'm seeing POST requests to /api/v1/read when querying.
The full HTTP Request headers for an example query are as follows (with the query as payload):

POST /api/v1/read HTTP/1.1
Host: localhost:9090
User-Agent: Go-http-client/1.1
Content-Length: 80
Content-Encoding: snappy
Content-Type: application/x-protobuf
X-Prometheus-Remote-Read-Version: 0.1.0
Accept-Encoding: gzip

What you expected to happen
The query process to fully use the prometheus.url value as provided by sidecar.
How to reproduce it (as minimally and precisely as possible):

Run Prometheus with a URL prefix: --web.route-prefix=/prometheus/
Start sidecar pointing to the URL with the prefix: --prometheus.url http://localhost:9090/prometheus
Send a query to the Thanos query process

Full logs to relevant components
The logs don't show anything relevant. When using the webinterface of the query process to execute a query the following message is shown:

receive series: rpc error: code = Unknown desc = query Prometheus: request failed with code 404 Not Found

This makes sense as Prometheus expects requests to /prometheus/*
Please let me know if you need anything else.

Thanks for reporting, makes sense

First time Golang, luckily it was an easy fix


postgres: cloudctl postgres ls should show if a postgres is primary or standby

postgres: cloudctl postgres ls should show if a postgres is primary or standby
this would be really helpful as the approach to check for
connection:
    localsideisprimary: false

or
connection:
    localsideisprimary: true

via cloudctl postgres describe <id> -o yaml only seems to work with extended rights

cloudctl postgres describe -o wide does show this already, albeit somewhat cramped.
I think something like cloudctl postgres describe -o replication would be more useful.

Using the -o wide option with the cloudctl postgres ls is what I was looking for, I did not know that option:
cloudctl postgres ls -o wide
closing this issue.


Update pkill to continue script

Hi! Thanks for an outstanding framework ✨
I notice that when I run this TTP, it doesn't seem to run successfully whether or not Firefox is running. If Firefox is running, it closes but errors. When Firefox isn't running, it errors. I think it's because the pkill statement is returning status of 1 either on the first or second pkill call.
# firefox not running
% pkill -a -i "Firefox"
% echo $?
1

This PR adds || true to tell the script to continue. I'm not sure why the second pkill is there but I added the same to both lines. This unblocks this locally for me.
Proposed Changes
Prevents the script from stopping if Firefox is not running or has been killed.
Related Issue(s)
None, but could make one if that helps.
Testing
Manually tested on macos. Happy to contribute to specs.
Documentation
Please point me in the right direction if this is needed.
Checklist

[ ] Ran mage runprecommit locally and fixed any issues that arose.
[x] Curated your commit(s) so they are legible and easy to read and understand.
[ ] 🚀

I'll close this.


fix: only do openssl tricks on non-windows

This fixes the windows-msvc target, at least locally. However tests now fail due to snapshotting extensively using un-normalized paths, so ./ becomes .\, which can be fixed in several places that I don't want to make the call on.
(I also reflexively ran cargo fmt, lmk if you want me to revert those driveby changes)

Summary by CodeRabbit

Refactor

Improved portability and clarified usage of OpenSSL across different platforms.

Style

Code cleanup including removal of unnecessary whitespace and empty lines.

Tests

Minor test modification for enhanced functionality.

However tests now fail due to snapshotting extensively using un-normalized paths, so ./ becomes ., which can be fixed in several places that I don't want to make the call on.

I'm assuming this might just be locally on Windows - let's see how CI responds.

Specifically:
  crates/cli_bin/tests/apply.rs (basic_terraform_apply)
  crates/cli_bin/tests/apply.rs (compact_output)
  crates/cli_bin/tests/apply.rs (markdown_pattern_with_invalid_name)
  crates/cli_bin/tests/apply.rs (multifile_terraform_apply)
  crates/cli_bin/tests/apply.rs (output_jsonl)
  crates/cli_bin/tests/apply.rs (terraform_complex)

Although terraform_complex has an actual output change, there 4 matches becomes 0 matches.

Opened https://github.com/getgrit/gritql/issues/245 to track the path normalization. We probably do want to run Windows tests once we have a Windows release.


Allow custom telemetry handlers

Tell us more about this new feature.
Background
Different users of the mountpoint client are likely to be interested in different metrics that are relevant to their usecase. In order to support all of them, it would be nice if they could define a custom telemetry handler for their client & then whenever the on_telemetry callback is run, that handler is run as well.
For context, our client downloads different parts of the same object in S3 at high concurrency. We think there is some sort of throttling/slowdown going on somwhere along the request path, but in today's mountpoint we have no way of injecting metrics/logging for requests where the bandwidth is < X MB/s or the duration > Yms. It doesn't really make sense for mountpoint itself to support this usecase, but it also makes sense that users should have the capability to do this themselves
I'll be submitting a PR for this issue, but creating the issue as well if discussion is necessary.

Hey @aws-hans-pistor, thanks for opening the issue and proposing the code change. We'd like to understand the use-case a bit better before proceeding.
I can see that the client already logs some information from telemetry with each HTTP request after it finishes (note that a single call to the client's method, e.g get_object,  may result in multiple underlying HTTP requests, e.g. HeadObject + multiple GetObject-s). You need DEBUG level logging to get those logs.
Even more information is logged when the TRACE level is enabled (1, 2).
Ain't this logging sufficient for your use-case? If some information is not extracted from the CRT (e.g. extended request ids) we can consider fixing this for all users of the client.
From the description it looks that you are also looking for a better way of controlling the verbosity of the logs:

way of injecting metrics/logging for requests where the bandwidth is < X MB/s or the duration > Yms

Does it mean that today's TRACE logs are too verbose for your use case and you'd like to have a callback to do custom logging based on data in RequestMetrics? Is the operation: &str required for this? Note that you can extract the type of the HTTP request from RequestMetrics.

TRACE/DEBUG logging is not really feasible at the scale we're running because we can't control what is logged & what isn't. We need finer grained controlled on what & when we log / emit metrics on.
As for the parameters on the custom logging, that's up to you. I was more or less copying the inputs to the existing telemetry callback, which require the RequestMetrics and the operation that pulled from the Span


Rename decode function unsafe_decode to highlight the risk

Describe the problem you'd like to have solved
I'm a DevSec. I help developers teams find and fix their vulnerabilities.
In two of my last missions, I've seen developers using decode instead of verify even if the documentation has been improved.
Describe the ideal solution
To avoid this and reduce the vulnerable apps, I think it would be great to rename the decode function and call it unsafe_decode.
Other libraries have done it and it helps developers reduce their mistakes:

dangerouslySetInnerHTML for React
bypassSecurityTrustHtml for Angular

I can make a Pull Request if you think it is a good idea.

Very interesting proposal. I would just suggest calling it unsafeDecode instead to maintain the same camel case naming

I would suggest unverifiedDecode to keep it within the same wording as verify() function. I think it also would be nice to be able to take this unverified decoded token and verify it (see #955). Code would then be something like:
const unverifiedToken = unverifiedDecode(rawToken);
const verifiedToken = verify(unverifiedToken );

Hi @jonaskello,
I think unverifiedDecode is less clear for developers.
It should be evident that it is dangerous!
Also, verifying a token after it has been decoded is impossible.
The JWT is split into three parts: header, payload and signature. If the JWT is modified, the signature is not valid anymore.
When you decode the JWT, you only get the payload (without the base64 encoding) so you can't verify the signature anymore.
I hope it's clear.
@aalu-love, thanks for the PR. Would you update it to use camelCase as @youssef-jbili suggested? Otherwise, I can do it at the end of the week 😁

@marine-mb When you decode you get all three parts as can be seen here
return {
      header: decoded.header,
      payload: payload,
      signature: decoded.signature
    };

So not only the payload. However I think you might be saying the signareture is calculated on the raw base64 string? In that case I understand the limitation.

@marine-mb When you decode you get all three parts as can be seen here
return {
      header: decoded.header,
      payload: payload,
      signature: decoded.signature
    };

So not only the payload. However I think you might be saying the signareture is calculated on the raw base64 string? In that case I understand the limitation.

Hi @jonaskello,
Thank you for your answer.
My mistake, the signature can still be recovered. However, as you said, you still need the encoded token for the verification.
As seen here in the verify function, we give the encoded JWT as a string with the algorithm and the key (secret or public) to jws library.
So we would have to encode it again.
And even if we could give the decoded token, I think it is dangerous to give the impression it is correct to exploit data in the JWT before verifying the signature.
It could lead to flaws such as injections, broken access control, etc...

https://github.com/auth0/node-jsonwebtoken/pull/972 would allow sanitising/verifying the token payload without using decode, so if using decode to check validity of the token then this MR would remove the need for it.
For example if a backend is expecting a certain property to be a certain value e.g. clientId === 123, we can now achieve this without using decode at all


Signup Register page

The signup/Register can replace to the starting page of the game so the Adventure to name them.

Please assign it and give labels

@YadavAkhileshh  Please assign it and give labels

I would like to work on this issue. Could you please assign me this task with difficulty label


v2022.11.01 Clion & Intellij Release

Hello, Please let us know if there are any changes you want to add in release. Thanks!

Enable the Autoscroll to console by default (#4006)
Internal cleanup to support IJ 2022.3


Determine whether users use create Env feature

Added some telemetry

Codecov Report

Merging #12428 (60dfc9a) into main (101e248) will decrease coverage by 0%.
The diff coverage is 50%.

@@          Coverage Diff           @@
##            main   #12428   +/-   ##
======================================
- Coverage     69%      69%   -1%
======================================
  Files        496      496
  Lines      31426    31434    +8
  Branches    4925     4925
======================================
- Hits       21990    21973   -17
- Misses      7595     7613   +18
- Partials    1841     1848    +7

Impacted Files
Coverage Δ

src/telemetry.ts
7% <0%> (-1%)
:arrow_down:

...ks/controllers/pythonEnvKernelConnectionCreator.ts
63% <57%> (-1%)
:arrow_down:

...otebooks/controllers/controllerPreferredService.ts
72% <0%> (-4%)
:arrow_down:

src/kernels/kernelDependencyService.node.ts
80% <0%> (-3%)
:arrow_down:

...ractive-window/editor-integration/codeGenerator.ts
89% <0%> (-3%)
:arrow_down:

src/kernels/errors/kernelErrorHandler.ts
56% <0%> (-2%)
:arrow_down:

.../notebooks/controllers/vscodeNotebookController.ts
85% <0%> (-2%)
:arrow_down:

src/platform/api/pythonApi.ts
70% <0%> (-1%)
:arrow_down:

src/kernels/raw/launcher/kernelProcess.node.ts
73% <0%> (-1%)
:arrow_down:

src/interactive-window/interactiveWindow.ts
68% <0%> (-1%)
:arrow_down:

... and 7 more


[P4-PDPI] Add references library to help handle p4 table entry dependencies.

sonic-buildimage/src/sonic-p4rt/sonic-pins$ ~/keyword_checks.sh .
Keyword check Passed.
/sonic/src/sonic-p4rt/sonic-pins$ bazel build $BAZEL_BUILD_OPTS  ...
Starting local Bazel server and connecting to it...
INFO: Analyzed 401 targets (243 packages loaded, 19863 targets configured).
INFO: Found 401 targets...
INFO: From Compiling sai_p4/instantiations/google/test_tools/test_entries.cc:
In file included from ./gutil/proto.h:26,
from sai_p4/instantiations/google/test_tools/test_entries.cc:30:
sai_p4/instantiations/google/test_tools/test_entries.cc: In function 'absl::lts_20230802::StatusOr<std::vectorp4::v1::TableEntry > sai::MakePiEntriesForwardingIpPacketsToGivenPort(absl::lts_20230802::string_view, const pdpi::IrP4Info&)':
sai_p4/instantiations/google/test_tools/test_entries.cc:144:75: warning: 'absl::lts_20230802::StatusOrsai::TableEntries sai::MakePdEntriesForwardingIpPacketsToGivenPort(absl::lts_20230802::string_view)' is deprecated: Use EntryBuilder().AddEntriesForwardingIpPacketsToGivenPort(egress_port).GetDedupedPiEntities(ir_p4info) instead. [-Wdeprecated-declarations]
In file included from ./p4_pdpi/pdgenlib.h:25,
from p4_pdpi/pdgenlib.cc:15:
bazel-out/k8-fastbuild/bin/p4_pdpi/ir.pb.h:14031:1: note: declared here
14031 | IrActionDefinition_IrActionParamDefinition::references() const {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INFO: Elapsed time: 661.784s, Critical Path: 27.19s
INFO: 150 processes: 6 internal, 144 linux-sandbox.
INFO: Build completed successfully, 150 total actions
sonic/src/sonic-p4rt/sonic-pins$ bazel test $BAZEL_BUILD_OPTS ...
INFO: Analyzed 401 targets (0 packages loaded, 0 targets configured).
INFO: Found 260 targets and 141 test targets...
INFO: Elapsed time: 3.029s, Critical Path: 0.80s
INFO: 4 processes: 5 linux-sandbox.
INFO: Build completed successfully, 4 total actions
//gutil:collections_test                                        (cached) PASSED in 1.1s
//p4_pdpi/testing:references_test                                        PASSED in 0.3s
//p4_pdpi/testing:references_test_runner                                 PASSED in 0.2s
Executed 3 out of 141 tests: 141 tests pass.
INFO: Build completed successfully, 4 total actions

Co-authored-by: Srikishen Pondicherry Shanmugam
<EMAIL_ADDRESS>


Http listings cache

Fixes https://github.com/intake/filesystem_spec/issues/621
Closes #560

Dear Martin,
thank you very much for taking over and integrating this patch!
With kind regards,
Andreas.


Enable proxy configuration for tinkerbell workload cluster

Issue #, if available:
Description of changes:
With this PR, I am adding a functionality to enable proxy configuration for workload cluster create and upgrade for tinkerbell provider.
Testing (if applicable):
I have ran the following tests manually,

Management cluster create
Management cluster upgrade
Workload cluster create
Workload cluster upgrade (TODO)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/test eks-anywhere-presubmit

/approve


Remove explicit outdated parmed dependency and add rc channel

Removes outdated explicit parmed dependency since up-to-date parmed is already included in ambertools
Test against omnia/label/rc openmm==7.4.2 rc as well
Require OpenMM >=7.4.1

The current failures are due to
Failure: RuntimeError (ParmEd is too old, please upgrade to 2.0.4 or later) ... ERROR

which is appearing because the latest ambertools=20 on conda-forge returns an erroneous parmed.version:
https://github.com/conda-forge/ambertools-feedstock/issues/35

Once we fix openmoltools, this will hopefully stop failing.


eventColor - access line info

Is there a way of accessing the event line name when inspecting a datum within eventColor?
I am plotting different types of dates within a row and I would like to colour each datum based upon what type of date they are.
I have hacked around this by cycling through the data in all event lines for a given date type (within .eventColor) and returning the specific colour for that date type if the datum value matches. This breaks if the same date value exists elsewhere on another line, as the same colour will get assigned to both irrespective of data type.
An improvement would be to look when index becomes zero, as this will signify that the datum is on the next line to the previous and from this I can work out what line it belonged to.
I was wondering however if there is a nicer way of doing this, if there is a way of getting the line name for a datum within eventColor?
Or to be able to pass in multiple lists to the createEvent function and colour a datum based upon which list it came from?

Sorry for the delay.
If I understand you correctly, you want to be able to access some extra information from the passed data in every configuration functions? Would something like:
var data = [
    { name: 'Some data', data: [
        { date: '2014-05-02', foo: 'bar', extra: 'Lorem Ipsum' },
        // ...
    ] }
];

var chart = d3.chart.eventDrops()
    .eventColor(function (d) {
        return d.foo === 'bar' ? 'red' : 'green';
    })
    .eventClick(function (d) {
        console.log(d.extra);
    });

Fulfill your need?

@jpetitcolas I am curious about the eventClick event. I am having difficulties with it firing from your example:

var eventDropsChart = d3.chart.eventDrops().start(new Date('Jan 1, 2015'))
    .eventClick(function (d) {
        console.log(d);
    });

Just to make things clear: the snippet above is not currently implemented, but is an idea for a future implementation. Currently, d should only be the drop date.
We fixed recently event handlers. I've just rebuilt library. Can you retry with last master version?

+1, eventClick and eventHover is now working!
I am building a tooltip so I can inspect events, is this feature in the official roadmap?

Yes, I think we are going to embed it in a 0.2.1 or 0.3 version (depending if there are some backward compatibility breaks). For now, we are focusing on delivering 0.2.0. :)

Sorry if this is the wrong place to ask, but is it possible to get the index and category on the eventHover event?

var data = [
{
name: "Stars",
dates: [new Date('2014/09/15 13:24:54'), new Date('2014/09/15 13:25:03')],
repos: ['test/test','debug/debug']
}, {
name: "Pushs",
dates: [new Date('2014/08/15 11:24:54'), new Date('2014/09/15 13:25:03')],
repos: ['test/test','debug/debug']
}];

Ideally even, if I could just get the repo name.

Can you just open a new issue to not pollute the original one? :)

Pull request #76 should enable this kind of input data and functionality.
var data = [
    { name: 'Some data', data: [
        { date: '2014-05-02', foo: 'bar', extra: 'Lorem Ipsum' },
        // ...
    ] }
];

var chart = d3.chart.eventDrops()
    .dateAttribute("date")
    .eventColor(function (d) {
        return d.foo === 'bar' ? 'red' : 'green';
    })
    .eventClick(function (d) {
        console.log(d.extra);
    });

I merged this request into my master repository since I want to get additional data. However, my the data does not render using the example you mentioned. Could you help me figure out what I could be doing incorrect here?
demo.js file attached.
demo.js.zip

Is there an rough ETA on a release for the above fix?

@oddieg: We'll release a 0.3 version once current four PR (up to #80) are merged.

Should be fixed by #76.


Use localization friendly links in English main site.

This is a Feature Request
What would you like to be added
The intra-site links in the English documents are currently plain markdown links, as shown below:
* Learn about [Controllers](/docs/concepts/architecture/controller/)

When pages containing such links are translated into another language, the localization team has to take extra care to handle them or else the links will be missing or pointing to an incorrect location. For example, in the Chinese localization, the above line has to be revised to something like:
* 进一步了解 [控制器](/zh/docs/concepts/architecture/controller/)

We need to revise this links to one of the following formats so that the links can be automatically converted to the correct target:
* Learn about [Controllers]({{< relref "docs/concepts/architecture/controller.md" >}})
* Learn about [Controllers]({{< ref "/docs/concepts/architecture/controller.md" >}})

For English main site and all localization sites, the above links can be correctly converted.
Why is this needed
Taking care of so many links for so many localization, across so many teams is error-prone and boring. Once we have the links on the English main site refactored. All localization teams can simply skip updating the link  target.
As a bonus, if a link target doesn't exist in a particular language, Hugo can detect the missing link and report errors during build. So we can detect missing links as early as possible.
Comments
For related experiments, see #18374

:100: this
To be honest, when I started contributing I saw that there were localizations and I assumed that a mechanism similar to this already existed. I was genuinely surprised when I realized that localization teams needed to manually track this kind of detail.

/kind feature
Does /priority important-longterm feel right?

No objections wrt priority. :)

/priority important-longterm

This is interesting!
Looking at the Hugo docs,
https://gohugo.io/content-management/cross-references/
How does this workk?
{{< relref path="document.md" lang="ja" >}}

Right, if you explicitly provide a lang param, hugo will try redirect you to the specified localization. One use case, in k8s/website could be that for some content, we want to redirect all anchors to the same language, say English.

@tengqm
Is it appropriate to add /zh directly in front of it right now?
/cc @yuxiaobo96
thanks your job!

@sftim @tengqm
Is there any progress on this matter?

I think the modification proposed by tengqm is better.

@tanjunchen No progress yet. If the proposed approach makes sense, we may need to revise the English site as early as possible.

@tanjunchen No progress yet. If the proposed approach makes sense, we may need to revise the English site as early as possible.

done

Inspired by @tengqm PR #18374 experiment, I have been proposed another PR #18678 for solving this issue.
For ref and relref, I did some research, see hugo 2637, there is no builtin function do check existence ONLY, and I found lang.Merge, but it seems not addressing this issue, see hugo 5612.
For these reasons, I think customized shortcode should be better, and PR #18678 is my answer.
Many thanks to @tengqm great job.

@feloy @rekcah78

How about this issue now ? see https://github.com/kubernetes/website/issues/18929
They add ja in front of the path.
Is it currently possible to implement similar functionality directly by modifying the hugo code.
/cc @tengqm
/cc @Colstuwjx

@tanjunchen It is not gonna be a trivial change. I'm not a big fan of adding/modifying hugo code in this repo.

@tengqm Do you have any idea about solving this issue?
I think it should be a common issue for multilingual site, and we may need to make a conclusion about how to fix this issue at first, and then try to propose a PR for fixing it, here are some considerations in my mind:
We already have multilingual configurations, such as supported languages and their weight, content dir, language alternatives etc, if we could add something for configuring this link convert, for example like adding configuration makeRefAddLangPrefixByDefault=true.
If it's been set true, we could make hugo adding the language prefix by current dir language and its alternative language, therefore, we didn't need to handle this job by manually anymore...
If someone didn't prepare the translation placeholder for the ref, hugo should try to make the ref link fallback to the alternative language, and if it still fails, hugo should panic and throw errors, just like the shortcode ref and relref did.
What do you think about this solution? Or it's welcome if you have another better and workable solution. If we could make a conclusion, and it needs do some job with hugo upstream, I'm ready to do this.
Thanks.

The makeRefAddLangPrefixByDefault=true suggestion sounds good at fist glance. However, from Hugo developer's perspective, it may not be a priority since there are already existing facility to achieve the same goal. We may even conclude that our current way of codifying intra-site links are wrong. We SHOULD have used the localization friendly way to do this.

We SHOULD have used the localization friendly way to do this.
Yes, I was also wondering about this. I don't have any idea about which is the right way to do this, so I leave a comment on hugo repo, maybe hugo dev could give us some suggestions.

We SHOULD have used the localization friendly way to do this.
+1
@Colstuwjx  I have no good idea.

still relevant.
/remove-lifecycle rotten

@tengqm would you like to help us for this issue? I was wondering what else needed besides the config itself.

@irvifa Please check PR #19526 for the proposed changes.

My #1 favorite approach would be for a localization team to write something like:
* 进一步了解 [控制器](/docs/concepts/architecture/controller/)

and for the generated HTML to link to https://kubernetes.io/zh/docs/concepts/architecture/controller/ (or whatever language code is appropriate.
If Hugo can't yet do this, it might even be feasible to look into tweaking Hugo itself.

/reopen
Oops. Misclick.

/remove-lifecycle stale

I would like to /reopen this ticket in light of Hugo's ability to render links via https://gohugo.io/render-hooks/links/. This option can be used to implicitly add a language prefix to links. Thus, all valid Markdown links [text](/docs/…) in the text can receive a language prefix if there is a localized document.
Any advice and suggestions are welcome 🙏
PS. My WIP is here https://github.com/Andygol/k8s-website/pull/160 🚧

@sftim 🛎 ☝

Ack. I've seen the message @Andygol.


Where is models/vgg.lua for ENet-Label-Torch

If I train from scratch init.lua tries to load vgg.lua yet it is not found in the repo.
Can you provide the file that you used?
Thanks,
Mike

I think maybe what you want is vgg.t7. You can find it here. It is put in SCNN-Torch.


masonry: set pointer-captured ancestors of hover target as hot

Currently when a widget has pointer capture and the pointer is over one of its descendants, no widget is considered hot. This changes the hot logic such that the widget with the pointer capture and its ancestors are considered hot, but not its descendants.
The current behavior is troublesome. For example, when applying the following patch, a button does not register as having been pressed when the pointer is pressed while over its descendant label. That's because during the PointerUp event, the button is not considered hot (it has captured the pointer, but the pointer is not directly over the button: it's over its descendant label).
diff --git a/masonry/src/widget/widget_ref.rs b/masonry/src/widget/widget_ref.rs
index 2f85ea5..3494fcd 100644
--- a/masonry/src/widget/widget_ref.rs
+++ b/masonry/src/widget/widget_ref.rs
@@ -191,7 +191,8 @@ impl<'w> WidgetRef<'w, dyn Widget> {
             }
             // TODO - Use Widget::get_child_at_pos method
             if let Some(child) = innermost_widget.children().into_iter().find(|child| {
-                !child.widget.skip_pointer() && child.state().window_layout_rect().contains(pos)
+                child.state().window_layout_rect().contains(pos)
             }) {
                 innermost_widget = child;
             } else {

I think the current design is closer to right.
Part of the problem is that child label widgets are currently used to implement text layout for buttons and checkboxes, but really, button and checkboxes should fundamentally be unified widgets without children. skip_pointer is mostly an escape hatch.

For the keyboard, has_focus is true when any descendant has focus, though.

We could probably rename it, it's not a great name.

I'd suggest closing this PR and renaming has_focus to subtree_has_focus in a different PR, if that's fine with you?

I agree. An alternative to unifying widgets, could be to generalize skip_pointer to something like non-interactive subtrees: then you're still able to compose widgets (e.g., a button with an arbitrary widget acting as an icon).

Yeah, I do see the appeal. "Non-interactive" would basically be a top-down flag like "disabled" and "stashed" currently work.


Feature Request: Selected discussion based blog instead of whole category

In the current situation, the blog plugin moves all the content in the category to the blog section without any filter, so a lot of content appears. In the following process, an option can be added where the content selected by the site administrator can be displayed in the blog section, not based on category.

You could just create a secondary tag that only admins have permissions to, and add that tag to discussions. I think that should be the way to do it imo.

I have created blog-posts tag which has admin permissions. After I add this tag to discussion but its main category does not show on blog homepage's category navbar. For example there is a dicussion has military tag and blog-posts tag, I set to show only blog posts thus I can see only I selected discussions. But I can't select military category on blog homepage.

I think I see what you mean. Yes it would be very nice to be able to show the primary tag category filters of discussions that are tagged with a secondary blog tag. So not all discussions show, but you can select which ones and still provide meaningful category filters.
I'm doing what you are doing, and selecting specific posts from existing discussions but I don't want all in that primary tag to be a blog post, so I apply the secondary tag designated for blogs, but it means that I have basically one category on the blog page.
Hopefully that makes sense to Jasper and v17 team, and why it would be great to have this feature! :)

Thank you very much for your valuable contibution. I am trying to do similar thing like these website:
forum- (sozluk) : https://eksisozluk.com/entry/4062210
blog : https://seyler.eksisozluk.com/mutfak-konusunda-annelerin-vazgecilmezi-olan-tupperwarein-ilginc-tarihi
Forum Entry

Blog Post


Fix generated API documentation with selectable output type

After the fix to #753 ("404 not found does not respect default output format"), API documentation didn't work anymore if using a hug.output_format.accept() construct as the default output format.
This patch adds a failing test and a fix for this.
I was confused whether to base this on master or develop. Let me know if I need to rebase.

Coverage remained the same at 99.5% when pulling a263d3417e441aaf8424793e686c80dd2f1043f4 on akaihola:fix-documentation-with-selectable-output_type into 4801e1d0522d1f3c341752a238deb6e56f36384d on timothycrosley:develop.

Hi @akaihola,
Thank you for fixing this! I've pushed out your changes to PYPI:  https://github.com/timothycrosley/hug/releases/tag/2.4.7
The way the hug repo is set up, all code check-ins are done in develop and when merged into master automatically deployed - which is to say you made the right choice :).
Thanks!
~Timothy


w2dynamics test failing

@ladinesa , @lauri-codes pointed out that the test_w2dynamics.py is failing after my last merge. The part failing is the last one about asserting the Fermi energy (it happens locally too):
 >       assert sec_scf[0].energy.fermi.to('eV').magnitude == approx(14.15922513307991)
E       AttributeError: 'NoneType' object has no attribute 'fermi'

Strangely, I was debugging with VSCode to this file, and I can retrieve the value as in the test. When uploading the file to the local nomad installation, I can see:

I can deactivate the test, but if you have any ideas why, I can try to implement the fix.

I can have a look later today.

I think the reason is archive is missing m_context. For local tests to pass, you should put the assignment of the energy fermi out of the loop since it does not use the context for the hdf storage..

Ok, I can leave the tests out.


Fix #4089 Linked account cancel

VSCode serialization changed rejection handling to only serialize errors, which caused things to break

Changed to return either account info or a cancel message in the resolve
Rewrote to use promises. Tracking how to return canceled through 4+ thenables was way trickier than just using a promise
Updated unit tests to handle new scenario
Tested integration tests, realized they a) didn't run and b) didn't passed.

Added vscode dev dependency to fix run issue
Fixed tests to account for behavior changes in tree state.

@anthonydresser any issues? I addressed the 1 comment here, and fixed build break caused by vscode.d.ts conflicts. I didn't see an approved / request changes from you?

@anthonydresser all comments should be resolved. I didn't see you request changes - are there any blockers to signoff here?


_ci_prepare_view_vars typo?

I guess get_object_vars($object) should be get_object_vars($vars) ?
protected function _ci_prepare_view_vars($vars)
{
	if ( ! is_array($vars))
	{
		$vars = is_object($vars)
			? get_object_vars($object)
			: array();
	}

Duplicate of #4975.
Please use the search bar before opening new issues.

Alexander, i'm a club player cooee and youtuber,
I took mt to get in touch with you, I was wondering if you can do a short interview for my cooee club channel.
All cooee club players in brazil want something more than a sign of your visa, please.
My channel on YouTube is called IMPERIO GAMER PLAY.
Thanks for listening.
And I'm sorry I'm translating this because I'm Brazilian and I speak Portuguese.


changing search command description

replacing the default description with the actual one

Hi, I really like the project and would like to contribute to it. Hope that you don't mind. If this description was there on purpose, please close PR. Thanks!

@katarzynakawala sorry for the delayed response, I was very busy with college work, so didnot notice the pr. Let me review this today and get back to you.

@katarzynakawala Thanks for liking my project. Please feel free to go through the code-base and contibutions.md file and design docs mentioned at the end of the project description. Thanks for this PR.

Hi @qascade Thanks for accepting!


google crome, EQ not working on my music.

EQ is not working on my google crome 10 please help !

why EQ EQaudio on you tube not working on google crome 10# on all audio! please help me?


sql method throw error with template string

Environment
node 20.12.1
nitropack  2.9.6
better-sqlite3 9.6.0
Reproduction

The following code works well without template string:

const { rows } = await db.sql`SELECT * FROM bilibili_like`

The following code throws error without template string:

const tableName = 'bilibili_like'
const { rows } = await db.sql`SELECT * FROM ${tableName}`

Error:
[nitro] [unhandledRejection] SqliteError: near "?": syntax error
    at Database.prepare (/root/code/nitro-app/node_modules/.pnpm/better-sqlite3@9.6.0/node_modules/better-sqlite3/lib/methods/wrappers.js:5:21)
    at Object.prepare (file:///root/code/nitro-app/node_modules/.pnpm/db0@0.1.4_better-sqlite3@9.6.0/node_modules/db0/connectors/better-sqlite3.mjs:24:29)
    at Object.sql (file:///root/code/nitro-app/node_modules/.pnpm/db0@0.1.4_better-sqlite3@9.6.0/node_modules/db0/dist/index.mjs:34:38)
    at Object.run (file:///root/code/nitro-app/.nitro/dev/index.mjs:928:17)
    at runTask (file:///root/code/nitro-app/.nitro/dev/index.mjs:610:36) {
  code: 'SQLITE_ERROR'
}

Describe the bug
sql method throw error with template string
Additional context
No response
Logs
No response

@gyhyfj please use staticParameters while using template literals in sql queries.
TLDR; fix like this:
const tableName = 'bilibili_like'
const { rows } = await db.sql`SELECT * FROM {${tableName}}`

Explanation: when you use template literals, db0 automatically converts them to prepared statements and tableNames are not allowed to be part of prepared statements.
Detailed Discussion: #77

This issue can be closed now. Documentation initiative is being tracked in #77


Level geometry not loading properly

There are a lot of misplaced or outright missing walls in the levels with the unlocker enabled.
This is especially noticable at the site of grace in Murkwater Coast and when travelling down the Siofra River Well Depths elevator.
https://imgur.com/a/Kalm1WW

turn off FoV changes, apparently it doesn't work as expected fully

Oh yeah that fixed it, thank you.

Fixed with v<IP_ADDRESS>


Exception in Actor example

Expected Behavior
Messages seem to be sent and received, but we get an unexpected exception.
Actual Behavior
== APP == 2020-08-19 21:12:31,290 {HH:mm:ss.SSS} [http-nio-3000-exec-17] ERROR o.a.c.c.C.[.[.[.[dispatcherServlet] - Servlet.servic
e() for servlet [dispatcherServlet] threw exception
== APP == java.lang.IllegalStateException: Could not find timer astmessagedae-459d-b2da-ef94767049f5_Timer_1 for actor DemoActor.
== APP ==       at io.dapr.actors.runtime.ActorManager.lambda$invokeTimer$7(ActorManager.java:126)
== APP ==       at reactor.core.publisher.MonoSupplier.call(MonoSupplier.java:85)
== APP ==       at reactor.core.publisher.FluxFlatMap.trySubscribeScalarMap(FluxFlatMap.java:126)
== APP ==       at reactor.core.publisher.MonoFlatMap.subscribeOrReturn(MonoFlatMap.java:53)
== APP ==       at reactor.core.publisher.Mono.subscribe(Mono.java:4090)
== APP ==       at reactor.core.publisher.MonoIgnorePublisher.subscribe(MonoIgnorePublisher.java:47)
Steps to Reproduce the Problem
Just run the actor sample.

This issue was caused by a bug in the fast http router introduced in release-0.7.0. PR: #1978 which pulled in the latest fast http router version fixed the issue.

Correction, not a bug, we didn't use as intended (copying the values) and in the latest release of the router they changed the implementation to automatically copy it so users don't get confused :)

This issue was caused by a bug in the fast http router introduced in release-0.7.0. PR: #1978 which pulled in the latest fast http router version fixed the issue.

Correction, not a bug, we didn't use as intended (copying the values) and in the latest release of the router they changed the implementation to automatically copy it so users don't get confused :)

Thats great @yaron2, does thi mean that with latest fasthttp, we don't have to worry about issues which have been fixed by this PR https://github.com/dapr/dapr/pull/1839 , it will be taken care by fasthttp correctly.

This issue was caused by a bug in the fast http router introduced in release-0.7.0. PR: #1978 which pulled in the latest fast http router version fixed the issue.

Correction, not a bug, we didn't use as intended (copying the values) and in the latest release of the router they changed the implementation to automatically copy it so users don't get confused :)

Thats great @yaron2, does thi mean that with latest fasthttp, we don't have to worry about issues which have been fixed by this PR #1839 , it will be taken care by fasthttp correctly.

To be clear, the issue was not with fasthttp, it was with the router that was built on top of fasthttp.

This issue was caused by a bug in the fast http router introduced in release-0.7.0. PR: #1978 which pulled in the latest fast http router version fixed the issue.

Correction, not a bug, we didn't use as intended (copying the values) and in the latest release of the router they changed the implementation to automatically copy it so users don't get confused :)

Thats great @yaron2, does thi mean that with latest fasthttp, we don't have to worry about issues which have been fixed by this PR #1839 , it will be taken care by fasthttp correctly.

To be clear, the issue was not with fasthttp, it was with the router that was built on top of fasthttp.

Is it this one https://github.com/fasthttp/router/issues/38?

This issue was caused by a bug in the fast http router introduced in release-0.7.0. PR: #1978 which pulled in the latest fast http router version fixed the issue.

Correction, not a bug, we didn't use as intended (copying the values) and in the latest release of the router they changed the implementation to automatically copy it so users don't get confused :)

Thats great @yaron2, does thi mean that with latest fasthttp, we don't have to worry about issues which have been fixed by this PR #1839 , it will be taken care by fasthttp correctly.

To be clear, the issue was not with fasthttp, it was with the router that was built on top of fasthttp.

Is it this one fasthttp/router#38?

Yep


ds

Problem solved
Short description of the bug fixed or feature added

PR-Codex overview
This PR focuses on improving the NFTRevealButton component by adding checks for batch data and enhancing the user interface with better handling of revealed batches.
Detailed summary

Updated TypeScript documentation link in next-env.d.ts.
Added a check to return null if batchesQuery.data is empty in reveal-button.tsx.
Introduced a condition to check if all batches are revealed.
Modified the option elements to disable those with batchUri equal to "0x" and added a "(REVEALED)" label.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

#5862  👈 (View in Graphite)
main

How to use the Graphite Merge Queue
Add either label to this PR to merge it via the merge queue:

merge-queue - adds this PR to the back of the merge queue
hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.


Delete functionality

•	You can now delete telegrams
•	Added a check to ensure you fill in the recipient field and the subject field, so you dont pay for empty messages
•	Fixed the issue of sent messages not showing until the script was restarted
•	Added a check to ensure the POBox of the recipient exists before sending the telegram.


refactor: Table components

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

The change looks good to me. However, I got an interesting warning from the browser console when running storybook yarn storybook:
http://localhost:9091/?path=/story/table--group-by
When clicking the setting bar and change the column selector or the column grouping:
Material-UI: A component is changing the controlled checked state of SwitchBase to be uncontrolled.
Elements should not switch from uncontrolled to controlled (or vice versa).
Decide between using a controlled or uncontrolled SwitchBase element for the lifetime of the component.
The nature of the state is determined during the first render, it's considered controlled if the value is not `undefined`.

The warning cannot be reproduced in the main. But I cannot figure out why the warning occurs.

@jessieweiyi thanks for your comment. I'll figure out on this

@jessieweiyi fixed it. It was an error with checked property of Checkbox component in BaseColumns

Thank you for the great work.


bug: presets.operators["d"] = nil does not disable pending operators

Did you check docs and existing issues?

[X] I have read all the which-key.nvim docs
[X] I have searched the existing issues of which-key.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
NVIM v0.9.0
Operating system/version
CentOS Linux release 7.9.2009 (Core)
Describe the bug
I'd like whichkey not to pop up when pressing the d key. For the most part this works however some other installed plug-ins, https://github.com/tpope/vim-surround and https://github.com/tommcdo/vim-ninja-feet for example, extend d and other modes with o-pending operators and those completion results are still shown by which-key even though I've included require("which-key.plugins.presets").operators["d"] = nil on start-up.
Here's part of my configuration (full reproduction at the bottom)

Click to expand
(Uses lazy.nvim)
-- Note: The full configuration truncated to only the relevant parts

{
    "folke/which-key.nvim",
    event = "VeryLazy",
    config = function()
        local which_key = require("which-key")

        which_key.setup {
            triggers_blacklist = {
                c = {"%", ">"},  -- Prevent mappings like %s/ from popping up
            },
            plugins = {
                presets = {
                    motions = false,
                    text_objects = false,
                    operators = false,
                }
            }
        }

        local presets = require("which-key.plugins.presets")
        presets.operators["d"] = nil

        which_key.register(
            {
                ["<leader>"] = {
                    c = "+file-ish prefix",
                    d = "+debug prefix",
                    f = "[f]ind text using hop-mode",
                    i = {
                        name = "+insert prefix",
                        d = "[i]nsert auto-[d]ocstring.",
                    },
                    r = "+run prefix",
                    s = {
                        name = "+misc prefix",
                        a = { "[s]plit [a]rgument list" },
                    },
                },
                ["<space>"] = {
                    name = "Space Switching Mappings",
                    A = "Show [A]rgs list",
                    B = "Show [B]uffers list",
                    E = "[E]dit a new project root file",
                    L = "[L]ines searcher (current file)",
                    S = {
                        name = "[S]witcher aerial.nvim windows",
                        A = "[S]witch [N]avigation",
                        S = "[S]witch [S]idebar",
                    },
                    W = "Open [W]orkspace (NvimTree)",
                    Z = "[Z]oxide's interative pwd switcher",
                    c = {
                        name = "+LSP [c]ode prefix",
                        a = "Run [c]ode [a]ction",
                    },
                    e = "[e]dit a `:pwd` file",
                    q = "Switch to [q]uickfix window, if open",
                    w = {
                        name = "+workspace LSP prefix",
                        a = "LSP [w]orkspace [a]dd",
                        l = "LSP [w]orkspace [l]ist",
                        r = "LSP [w]orkspace [r]remove",
                    },
                },
            }
        )
    end,
}

{
    "tpope/vim-surround"
}

{
    "tommcdo/vim-ninja-feet"
}

Steps To Reproduce

Install which-key.nvim and tpope/vim-surround as normal, using your favorite package manager
Load Neovim
Press the d key

You should see output that looks like this:

Expected Behavior
No pop-up to show because
local presets = require("which-key.plugins.presets")
presets.operators["d"] = nil

was included in the which-key.nvim configuration
Repro
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  { "tommcdo/vim-ninja-feet" },
  { "tpope/vim-surround" },
  {
      "folke/which-key.nvim",
      event = "VeryLazy",
      config = function()
          local which_key = require("which-key")

          which_key.setup {
              triggers_blacklist = {
                  c = {"%", ">"},  -- Prevent mappings like %s/ from popping up
              },
              plugins = {
                  presets = {
                      motions = false,
                      text_objects = false,
                      operators = false,
                  }
              }
          }

          local presets = require("which-key.plugins.presets")
          presets.operators["d"] = nil
      end,
  },
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

@ColinKennedy the docs indicate that you should disable operators before calling setup (refer to the comment in the example of this section).

I'd like to confirm what you're suggesting. If you mean "move the presets.operators["d"] = nil before setup, that doesn't work. If you use the reproduction file and load the repro with nvim -u /path/to/repro.lua and press d, which-key will pop-up and show s ➜ <Plug>Dsurround
I tried a few configurations but none of them work

Modified Repro using nil
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")
-- set stdpaths to use .repro
for , name in ipairs({ "config", "data", "state", "cache" }) do
vim.env[("XDG%s_HOME"):format(name:upper())] = root .. "/" .. name
end
-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)
-- install plugins
local plugins = {
"folke/tokyonight.nvim",
{ "tommcdo/vim-ninja-feet" },
{ "tpope/vim-surround" },
{
"folke/which-key.nvim",
event = "VeryLazy",
config = function()
local which_key = require("which-key")
local presets = require("which-key.plugins.presets")
presets.operators["d"] = nil
      which_key.setup {
          triggers_blacklist = {
              c = {"%", ">"},  -- Prevent mappings like %s/ from popping up
          },
          plugins = {
              presets = {
                  motions = false,
                  text_objects = false,
                  operators = false,
              }
          }
      }
  end,

},
}
require("lazy").setup(plugins, {
root = root .. "/plugins",
})
vim.cmd.colorscheme("tokyonight")
-- add anything else here

Includes "operators = false", only
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")
-- set stdpaths to use .repro
for , name in ipairs({ "config", "data", "state", "cache" }) do
vim.env[("XDG%s_HOME"):format(name:upper())] = root .. "/" .. name
end
-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)
-- install plugins
local plugins = {
"folke/tokyonight.nvim",
{ "tommcdo/vim-ninja-feet" },
{ "tpope/vim-surround" },
{
"folke/which-key.nvim",
event = "VeryLazy",
config = function()
local which_key = require("which-key")
      which_key.setup {
          plugins = {
              presets = {
                  operators = false,
              }
          }
      }
  end,

},
}
require("lazy").setup(plugins, {
root = root .. "/plugins",
})
vim.cmd.colorscheme("tokyonight")
-- add anything else here

Explicit plugin.operators = nil & empty setup call
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")
-- set stdpaths to use .repro
for , name in ipairs({ "config", "data", "state", "cache" }) do
vim.env[("XDG%s_HOME"):format(name:upper())] = root .. "/" .. name
end
-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)
-- install plugins
local plugins = {
"folke/tokyonight.nvim",
{ "tommcdo/vim-ninja-feet" },
{ "tpope/vim-surround" },
{
"folke/which-key.nvim",
event = "VeryLazy",
config = function()
local which_key = require("which-key")
local presets = require("which-key.plugins.presets")
presets.operators["d"] = nil
      which_key.setup {}
  end,

},
}
require("lazy").setup(plugins, {
root = root .. "/plugins",
})
vim.cmd.colorscheme("tokyonight")
-- add anything else here

None of the above work. I've tried more configurations that this but I hope this gets addressed. If you have an modified configuration that works, it'd be great if you can post it for me and any others who are experiencing this. Thank you.

@ColinKennedy I think you've misunderstood what the setting does. presets.operators will just disable the built-in Vim operators (and so as your picture clearly shows, which-key isn't showing things like dd, dw, etc). It won't disable the d motions coming from other plugins. In order to do that, you should use which_key_ignore or set ignore_missing.

It seems the best I can hope for with current functionality is ignore_missing as which_key_ignore doesn't prevent the pop-up from what I can tell. FWIW I knew that it was o-pending operators from other plug-ins that were causing the issue, just not the setting needed to disable them. I was able to piece together using the bits you provided. It'd still be nice to be able to disable pop-ups for selective keys but this is good enough for me. Thanks.

@ColinKennedy glad I could help :)


Fix demo.sh for MULTI_CNI

As demo::install-cri-proxy() causes a restart of the pods, it should
be done before demo::install-cni-genie(). Otherwise the modifications
done by demo::jq-patch() to /etc/cni/net.d get overwritten.
Signed-off-by: Gregory Vander Schueren<EMAIL_ADDRESS>Also, I noticed the MULTI_CNI demo runs with a single host. Is there any reason not to run it with 2 hosts like the regular demo? I would be interested in modifying it to have 2 hosts. Will I run into troubles if I do so? Thanks.

This change is

@pigmej @ivan4th PTAL and merge or reopen that.


onLoad function

Adds onLoad function to router that can be passed as a prop to Router and gets called when a new route finishes to mount

@developit the use case for this is to do stuff that requires the new route to be loaded, for eg. sending page view to google analytics along with impressions for all promo links (which require the new route to be mounted), let me know if you have any questions

@psabharwal123 hmm - what about onRoute() doesn't work for that? It gives you a reference to the new component. If you need it to be fully mounted adding a Promise tick or setTimeout(0) would do the trick.


Is this works on kafka version 0.10.0 ?

Hi
Thank for sharing nice kafka-vertx module.
I already have clustered kafka 0.10.0 installed, dose "vertx-kafka-service" works on kafka 0.10.0 version ?
And, If I make 10 instances of http rest api server embeding "vertx-kafka-service" producer processing, dose "vertx-kafka-service" also deployed with 10 instances ?

Hi,
I haven't tested it but i am pretty  sure it won't work with 0.10.0 since they are not binary compatible and the configuration propery names changed. If you like you can make a PR with these changes.
Regarding the number of instances. The producer and consumer are running in their own verticle which means the number of this verticles defines the number of created instance. Usually it's enough to create one producer or consumer per vertx app. In your other verticle you can register your handler or create a KafkaProducerService to communicate the the producer verticle.

I could be wrong but the kafka protocol states that they try to keep backward compatibility and I installed the latest confluent platform which is 0.10 and the consumer seems to work. Or am I crazy?

eemmirr, any plans to upgrade this to 0.10?

sorry for the long silence. I can try upgrade and will test it. If it works out will upgrade to the latest

@jinho-scenappsm: master is now running with <IP_ADDRESS>, I plan an releasing 1.3.0 when all PRs are merged.


Radix wallet does not detect ledger nano s with radix ios wallet

Radix wallet does not detect ledger nano s with radix ios wallet. Used the new babylon app and did all the updates it doesn't detect ledger nano s when the app is open but it can detect when the app is closed

Just to make sure: have you clicked past the "Pending Ledger review" screen?

@chiragverma  thanks for getting in touch. We are working on publishing our contributing guidelines, but while we do, we would like to clarify that Github Issues are primarily meant for the purpose of reporting problems or concerns relating to the source code, rather than functioning as an open bug tracker. This means that reported issues on Github may be closed and reported in our internal tracking system or added to our roadmap.
In order for us to be able to help you, please make sure to provide as much detail as possible, including:

iPhone model
iOS version
Browser
Browser version
iOS Wallet App version
Connector Extension version
Radix Ledger App version

Ledger Nano

Firmware version
microcontroller version
bootloader version
Radix Babylon Ledger App Version

And just to ensure... you are indeed launching the Radix BABYLON Ledger app, and not the Radix Olympia Ledger app? :)

@chiragverma thanka but I do actually need explicit versions, "latest" does not give me the information I need to help you, since many software companies do progressive rollout/delivery, thus it is possible you have a later version than what I can see/or the reverse. Which is why I need explicit version numbers.
It is also a way for me to see directly that "aha, this user is using Olympia Ledger App, since he/she said 0.3.1 but we never released such a version with Babylon Ledger app which had 0.7.7 as lowest".
It would also be helpful to know your host OS, is it Windows, Linux or macOS? And which version?
How did you install the Connector Extension (CE)? Through extension store in Chrome or direct download from our GitHub? (Also need to know CE version as stated above)
And just to make sure, when you let Chrome (CE) try to connect to your ledger - is Ledger Live or any other browser running? Only one single application can claim connection with Ledger, why you must ensure only Chrome is doing so. In fact, now for the purpose of debugging- best if you shut down all other application beside one single Chrome window, to mimimise risk of any other app claiming connectivity.
Did you ever get to see the small black/greyish window popped out by Chrome asking you to allow it connect to your Ledger? It is a "list" (with only one item) showing "Ledger Nano S" (or similar)? Or did you never get to that step?

@chiragverma please respond with All asked info, you missed some, eg browser version and Ledger firmware versions.
You are using quite an old macOS, do you have the ability to update it?

@chiragverma hey you didn't tell us the firmware of the Ledger Nano device itself. It is three versions:
MCU
Secure Elements
Boot loader
(You told me version of Ledger Live app, not the ledger device which is what we need to know)

@chiragverma also can you please try Chrome instead of Brave, we officially support Chrome at the moment.
So try that, and tell me Ledger firmware.
If does not work:
Probably best if you reach out to<EMAIL_ADDRESS>So that my colleagues who work with community support can communicate with you.
And I suspect this is not an iOS wallet issue but it is more a connectivity issue between your old macOS host, browser and ledger device.

Is it correct understanding that LedgerLive constantly proposes you to update Babylon Ledger App?

the app was a big failure this is the first time i am having this connectivity issues

I'm really sorry that you're experiencing problems. Unfortunately, not everything depends on us and our code. There are many moving parts involved and some of them are out of our control. We're doing our best to nail down and resolve the issue.

May I ask you to do the following? :

connect device, enter pin and start app (go past "Pending preview")
wait about a minute
try to connect to it from wallet

For any further assistance, if needed, please contact us at<EMAIL_ADDRESS>


Change gamemode mid platformer level

I play multiplayer globed levels on GD and I see people going into the pause menu and then changing into ufo or wave mid level without a portal. Is this possible on OpenHack?

No you have to download the geode mod "gamemode changer" the one that DOESN'T have the description "lets you switch between platformer and classic mode"


under line can not display in Rename Symbol Inputbox, when setting font=monospace and fontsize=14

Under line can not display in Rename Symbol Inputbox, when setting font=monospace and fontsize=14
VS Code version: Code 1.52.1
OS: Ubuntu 18.04

Window: Zoom Level is a condition too. Editor: Font Family=monospace,Editor: Font Size=14,Window: Zoom Level=0, the _ dispaly as a SPACE.

Thanks for clarifying. We have an item that is about replacing the simple input box with the text editor. That should also fix this https://github.com/microsoft/vscode/issues/53666. Leaving this item around but most likely it will be indirectly fixed when moving to the editor

closing this as dupe of https://github.com/microsoft/vscode/issues/53666


Sleuth headers get lost at the KStream output

Hello my friends,
I have the following functional style topology:

KStream input
filter
flapMap
aggregate
filter
map
KStream output

Input records comes with sleuth headers, but they get lost in the kafka stream.
FlapMap split one record into N Records.
I need every output record has same sleuth headers that the input record.
¿ what is the right way to do this ? ¿kafka streams binder has support for this requirement?
Dependency Versions:

spring-cloud-stream-binder-kafka-streams:3.0.1.RELEASE
spring-cloud-starter-sleuth:2.2.1.RELEASE

StackOverflow question: https://stackoverflow.com/questions/59635408/sleuth-with-spring-cloud-stream-binder-kafka-streams
thanks

@JavierGB Is this still a problem in your application? We had some recent discussion about slueth instrumentation in the binder. Have you found a workaround for your requirements?

Kafka Streams binder's integration with Spring Cloud Sleuth is documented here.  Closing this issue. Feel free to re-open if necessary.


Create reviewdog.yml

Issues associated with this PR
Your PR should present related issues you want to solve.
Solutions
You should show your solutions about the issues in your PR, including the overall solutions, details and the changes. At this time, Chinese is allowed to describe these.
UT result
Unit Test is needed if the code is changed, your unit test should cover boundary cases, corner cases, and some exceptional cases. And you need to show the UT result.
Benchmark
If your code involves the processing of every request, you should give the Benchmark Result.
Code Style

Make sure Goimports has run
Show Golint result

https://github.com/mosn/mosn/issues/1245


fast stop

which Fast stop? the "when you stop pressing movement keys "W,A,S,D" it will be fully stopped" or the "you will stopped when you shooting someone" ?

W a s d fast stop

which Fast stop? the "when you stop pressing movement keys "W,A,S,D" it will be fully stopped" or the "you will stopped when you shooting someone" ?

First one

#2039


Can't open a PDF with the following exception:              No implementation found for long com.shockwave.pdfium.PdfiumCore.nativeOpenDocument(int, java.lang.String) (tried Java_com_shockwave_pdfium_PdfiumCore_nativeOpenDocument and Java_com_shockwave_pdfium_PdfiumCore_nativeOpenDocument__ILjava_lang_String_2)

Hi @Nandan-Wewhare
please provide more information about how u get this error

body: Center(         child: PDF(           onPageChanged: (page, total) {             setState(() {               pageNumber = page+1??0;               totalPages = total??0;             });           },           swipeHorizontal: true,         ).cachedFromUrl(widget.url),
This is the code and the url is a string

@AbdOoSaed
This is the PDF url and is working just fine.
https://firebasestorage.googleapis.com/v0/b/rtunotes.appspot.com/o/defaultuploads%2FFirst Year%2Fhough trnsform.pdf?alt=media&token=40be5a98-d66d-496a-a4f2-afea7f50ef03

Did you find any solution for this? I need it asap please.
@AbdOoSaed


Update dependency workflow-cps-global-lib to v575

This PR contains the following updates:

Package
Update
Change

workflow-cps-global-lib
major
570.v21311f4951f8 -> 575.v24fa_0a_b_f7383

Release Notes

jenkinsci/workflow-cps-global-lib-plugin
v575.v24fa_0a_b_f7383
Compare Source

👷 Changes for plugin developers

JENKINS-68375 - LibraryMemoryTest#loaderReleased fails on Java 17 when support-core is present (#163) @basil

📦 Dependency updates

Bump actions/checkout from 3.0.0 to 3.0.2 (#160) @dependabot

Configuration
📅 Schedule: "after 5:00 am before 11:00 am" in timezone utc.
🚦 Automerge: Disabled due to failing status checks.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

Branch automerge failure
This PR was configured for branch automerge, however this is not possible so it has been raised as a PR instead.

Branch has one or more failed status checks


Changes to zurich platforms

I will take a look after I can connect properly to the platform in main, as some changes in the LO ip or it being off prevents me testing qibolab after the update.
[2024.02.14 17:56:06.615] WARNING HDAWG:dev8660: Include the device options 'HDAWG8/' in the device setup ('options' field of the 'instruments' list in the device setup descriptor). This will become a strict requirement in the future.
[2024.02.14 17:56:06.795] WARNING HDAWG:dev8673: Include the device options 'HDAWG4/' in the device setup ('options' field of the 'instruments' list in the device setup descriptor). This will become a strict requirement in the future.
[2024.02.14 17:56:07.618] WARNING SHFQC/QA:dev12146: Include the device options 'SHFQC/QC6CH' in the device setup ('options' field of the 'instruments' list in the device setup descriptor). This will become a strict requirement in the future.

The platform mentioned in main does not exist any longer.
So, until this problem we show up again, let's consider it outdated.


DM-29983: Add rubintv deployment

@SimonKrughoff In addition to the above, you'll also need to make the ArgoCD application resource.

In roundtable/deployments/app-land/kustomization.yaml add resources/rubintv.yaml.
Create the rubintv.yaml resource referenced above; it'll be like the one you made for segwarides

OK.  ArgoCD app added.


fixed wrong variable names in starter guide using azure openai

found this small error while trying to use ragas following the starter guide using azure openai
previously set azure_config should be referenced instead of azure_configs (which doesn't exist)

thanks a lot for the fix that @MichaelPerger 🙌🏽


e2e: PF5 upgrade fix

Fixes

https://issues.redhat.com/browse/HAC-4843
Description

Update the locators in tests to PF5.
Type of change

[ ] Feature
[ ] Bugfix
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[x] Other (please describe): Test

Screen shots / Gifs for design review

How to test or reproduce?

Browser conformance:

[x] Chrome
[ ] Firefox
[ ] Safari
[ ] Edge

[test]

[test]

[test]

[test]

[test]

/test pact

[test]

[test]

[test]

[test]

/retest

[test]

/retest

[test]

[test]

[test]

/retest

[test]


hot to change default font

Hello, Asciiinema community.
I'm a non-English speaking user, so I've used translation. Please excuse any rudeness in my tone.
I've searched and read through issues based on the default font but couldn't find any record similar to my situation. I'm self-hosting using Docker.
Is there an option to set a different font as the default font?

Hi,
Right now there's no global setting for that, but I think it's actually a quite good idea to implement this :+1:
Btw, as a non-English speaker never apologize for your English skills :)

+1 on this, would like to set my default to a nerd font, since many of my tools use nerd font symbols in them.

@XavierChanth would you like to set a default font for your user account, or for the whole self-hosted instance of asciinema server? Both seems like good ideas to me anyway :)

@XavierChanth would you like to set a default font for your user account, or for the whole self-hosted instance of asciinema server? Both seems like good ideas to me anyway :)

For my user account

I've just deployed #431 (plus few tweaks). Set your default font here: https://asciinema.org/user/edit


Make automatic distributed initialization work with Open MPI 5.x, PMIx, and PRRTE

Background
https://github.com/google/jax/pull/13929 introduced automatic JAX distributed initialization via the Open MPI Open Run-Time Environment (ORTE) layer and its orterun process launcher (also known by its many aliases mpirun, mpiexec, oshrun, shmemrun).
Upcoming Open MPI 5.x series releases do away with the previous ORTE infrastructure for one based around the PMIx standard via the OpenPMIx reference PMIx implementation and complimentary PMIx Reference Run-Time Environment (PRRTE); in Open MPI 5.x the mpirun/mpiexec launcher is simply a wrapper for the PRRTE prterun launcher.
PMIx and PRRTE has differing behavior to ORTE which makes the implementation introduced in https://github.com/google/jax/pull/13929 incompatible with Open MPI 5.x. With Open MPI 5.0 (now in its tenth release candidate) continuing to approach release, there seems to be value in preparing JAX for this change.
Considerations & Challenges
Continued compatibility with ORTE and orterun
The current implementation (as introduced in https://github.com/google/jax/pull/13929) is fully usable with Open MPI versions prior to 5.x, and it is important to maintain compatibility with these releases when introducing support for Open MPI 5.x. It is unclear to me whether it would be wiser to make the current implementation compatible with the PRRTE-based launcher, or to create a separate piece of code to handle it.
New behaviors
PMIx/PRRTE exposes relevant information differently than ORTE.

OMPI_VERSION=5.0.0rc10
OMPI_TOOL_NAME=mpirun
PRTE_LAUNCHED=1
PMIX_NAMESPACE=prterun-%{hostname}-%{num_job_id}@1
PMIX_RANK=0
PMIX_SERVER_URI41=prterun-%{hostname}-%{num_job_id}@0.0;tcp4://%{ip_v4_addr}:%{port}
PMIX_SERVER_URI4=prterun-%{hostname}-%{num_job_id}@0.0;tcp4://%{ip_v4_addr}:%{port}
PMIX_SERVER_URI3=prterun-%{hostname}-%{num_job_id}@0.0;tcp4://%{ip_v4_addr}:%{port}
PMIX_SERVER_URI2=prterun-%{hostname}-%{num_job_id}@0.0;tcp4://%{ip_v4_addr}:%{port}
PMIX_SERVER_URI21=prterun-%{hostname}-%{num_job_id}@0.0;tcp4://%{ip_v4_addr}:%{port}
PMIX_SERVER_TMPDIR=/tmp/prte.%{hostname}.%{uid}/dvm.%{num_job_id}
PMIX_SYSTEM_TMPDIR=/tmp
OMPI_COMM_WORLD_SIZE=1
OMPI_WORLD_SIZE=1
OMPI_MCA_num_procs=1
OMPI_COMM_WORLD_RANK=0
OMPI_COMM_WORLD_LOCAL_RANK=0
OMPI_COMM_WORLD_NODE_RANK=0
PMIX_HOSTNAME=%{hostname}
A selection of variables exposed to a process when launching with mpirun under Open MPI 5.x.

OMPI_MCA_orte_hnp_uri no longer exists, and the server URI is now instead exposed to the process via a family of PMIX_SERVER_URI environment variables (one for each supported version of the PMIx standard). This means that the current implementation is not activated at all by the PRRTE process launcher. Even if it was, the value of these variables are not the same as OMPI_MCA_orte_hnp_uri and require a meaningfully different handling: The identifier prior to the address is no longer exclusively numeric and instead is the base of the job namespace (exposed via PMIX_NAMESPACE), derived from the server tmpdir (exposed via PMIX_SERVER_TMPDIR), which itself is derived from the server hostname (exposed via PMIX_HOSTNAME) and the numeric job identifier.

Open MPI environment variables exposing the world size, world rank, and local rank are unchanged, but PMIx also exposes the world rank itself via PMIX_RANK.

Detecting if the process is launched with prterun is more convenient than with orterun: PRTE_LAUNCHED is set to 1.

@EricHallahan are you interested in implementing the support? cc; @nvcastet

@EricHallahan are you interested in implementing the support?

Prior to filing this issue, I made a patch to the existing implementation to make it work for Open MPI 5.x. I am willing to contribute it, but the question remains as to how to maintain support for earlier versions (something I didn't consider for my personal use) as they are going to remain in use for many years to come.

@EricHallahan Thanks a lot for raising this issue and the thorough discussion!
We detect current OMPI with ORTE via the presence of the env var OMPI_MCA_orte_hnp_uri: https://github.com/google/jax/blob/main/jax/_src/clusters/ompi_cluster.py#L28-L29
For OpenMPI with PRRTE you could contribute your patch as a new subclass of ClusterEnv, OMPI ORTE will not interfere since OMPI_MCA_orte_hnp_uri  will not be defined with PRRTE.
Does that make sense?

That is certainly a valid option! I'll go ahead and try that.

@EricHallahan could you contribute your patch, or maybe put it out there? It would be useful for me as well.

(And do you know if there is a way to do the same for MPICH by any chance?)

You can use auto-detection via mpi4py for that. See https://github.com/google/jax/pull/20174

I know, but I don't want to.
I get some errors with that...


runtimeCaching: options -> origin problem

Hey,
I tried to configure external domain caching through the runtimeCaching feature of sw-precache.
I used the options syntax for the external domain conf passed to the array runtimeCaching:
{                               urlPattern: /\/(.*)/,                               handler: 'fastest',                               options: {                                           cache: {                                                   name: 'googleapis',                                                   maxAgeSeconds: 864000                                                  },                                           origin: /\.googleapis\.com$/                                     }                             }
It was translated after grunt execution into (in the service-worker.js):
toolbox.router.get(/\/(.*)/, toolbox.fastest, {"cache":{"name":"googleapis","maxAgeSeconds":864000},"origin":{}});
As you can see, the origin parameter is an empty object and then, at runtime, everything is cached into the "googleapis" cache. Which is wrong :)
I then tried to declare the origin with quotes:
origin: '/\.googleapis\.com$/'
After grunt execution, it generated :
toolbox.router.get(/\/(.*)/, toolbox.fastest, {"cache":{"name":"googleapis","maxAgeSeconds":864000},"origin":"/.googleapis.com$/"});
Looks better (even if it changed my regExp).
But at runtime, all requests of my own domain get cached in the 'googleapis' cache. Even the already precached ones.
It works as if the origin had no effect (or is wrong, which is expected since the regExp has been changed).
I tried the same configuration straight into a mint sw-toolbox (outside of sw-precache) with this declaration:
toolbox.router.get('/(.*)', toolbox.fastest, {     cache: {       name: 'googleapis',       maxAgeSeconds: 864000       },     origin: /\.googleapis\.com$/   });
It works perfectly, only files from the googleapis.com domain are stored in the 'googleapis' cache.
My own domain files are stored in other caches, as expected.
I may be completely wrong, but it seems that the origin attribute is not well accepted by sw-precache 3.1.1 in the runtimeCaching.
A turnaround I found, was to put a mint sw-toolbox (3.1.1) and a custom-rules.js (for my rules) file in the importScript part of sw-precache. It works fine that way, but it is not a 'all-in-one' grunt approach.
It leads me to the question:
Does the runtimeCaching (with sw-toolbox embedded) feature support the origin option of the sw-toolbox ? if so, what is the syntax ?
Thanks !
Chenav

This should be resolved in https://github.com/GoogleChrome/sw-precache/releases/tag/3.2.0. Can you confirm?

Mmmmh, I could not make it work.
I updated sw-precache and I built a project with that declaration in my gruntfile:

Does not work properly at run time, as the 'googleapis' cache collects every fetch.
The service-worker.js file generated by the grunt still contains that expression (which "origin" attribute is wrong and does not filter on the 'googleapis.com' domain as it is empty - weird):

I do not think my declaration is wrong (it works in mint sw-toolbox), but I'll be glad if you could check.

Sorry for the misinformation re: https://github.com/GoogleChrome/sw-precache/releases/tag/3.2.0
I think I see what's going on, and it should be able to work around this if you use the urlPattern option to match on the full URL, like:
urlPattern: /\.googleapis\.com\//,

(feel free to tweak that RegExp if you need to be more restrictive).
The whole different-behaviors-when-using-strings-vs.-RegExp thing is unfortunate, and I apologize for that. I know that there are folks who are in favor of using strings for "routes" when using sw-toolbox directly, but I have a feeling that folks who are using sw-toolbox indirectly via runtimeCaching would benefit from just having a single, consistent approach, and that would rely on RegExps.
I'll leave this open to track that change.


Suggestion

Compatibility with levelZ so the scalling health works, like let us choose where we want the extra health to be

I see this is already second issue post for extra hp... according to the other post, it seems like you already have a implementation plan, that's cool. I'm going to just share what I had in mind before I came here:
Instead of hardcoded part hp, use a weight system that scales with player total hp to maximize compatibility. So to stay consistent with current default values, the weight of head should be 0.2 while torso weight being 0.3.


added objects to truthiness table

Resolves #34
I don't know whether you'll need to update your implementations, but this seems right to me.

@jwadhams any problems with this?


chore Fix the FE build on CentOS 6

Proposed changes
Issue Number: close #24799

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall


Populated repository with eyejet modules

Table of Contents
Description
Populated repository with eyejet's modules
Modules added:
eyejet - the main library
eyejet-annotation - contains the annotations used in the eyejet and is included inside it
eyejet-arch - contains internal executors used by the eyejet module and is included
Demo module - app
Contributing has more information and tips for a great pull request.

@zeobot set lc to pass


AsyncListener/AsyncPublisher supports ElementType.TYPE

Describe the feature request
AsyncListener/AsyncPublisher should support ElementType.TYPE as a target.
Motivation
In typical projects listeners/publishers are independent beans with dedicated methods for consuming/producing. However, sometimes (In bigger projects) the mechanism for consuming/producing are hidden in SDK/libraries. In that cases only simple POJO classes are representative for consuming/producing in the service. Due to that the mentioned annotations should be placed on class level.
Technical details
Supports for both - method and class - level should be implemented. If supporting both levels at the same time would be to painful, please think about parameter to control the behavior.
Describe alternatives you've considered
I tried to implement the feature as an extension to Springwolf. In fact, adding support to annotate POJO classes is quite simple (however maintaining the extension - with upgrading Springwolf itself - would be painful) but I occunterd problems where annotated classes are not so simple as POJO (e.g. beans). In that cases too deep type resolving are executed and in the end processing is broken with NPE from org.springdoc.core.converters.SchemaPropertyDeprecatingConverter#resolve (resolvedSchema is null).
Maybe supports only for POJO class level would be a good option at least at the start.
What do you think about such feature?

Hi @madrimas,
great idea. AsyncListener/AsyncPublisher can only be used on methods (and other annotations) at this point.
Just to double check, adding the annotation on the class level, would scan all containing methods of the class. Also, all methods would have the same configuration (channel name, bindings, description, while the payload can be extracted from the concrete method signature).
Actually, Springwolf has this already in mind.
Currently, there is only the method-based channelScanner (and operationScanner as well):
https://github.com/springwolf/springwolf-core/blob/07e38d92cce28c972751a53b0bf3b5f912e418d7/springwolf-core/src/main/java/io/github/springwolf/core/asyncapi/scanners/channels/AsyncAnnotationChannelsScanner.java#L28
In the case of kafka, a class level scanner already exist. This is probably a good starting point for adding a AsyncAnnotationClassLevel(Channels|Operations)Scanner:
https://github.com/springwolf/springwolf-core/blob/ef4c28c4fcbd9a4ecbc3c5bd6cd1b5646eba91f2/springwolf-plugins/springwolf-kafka-plugin/src/main/java/io/github/springwolf/plugins/kafka/configuration/SpringwolfKafkaScannerConfiguration.java#L59
We are happy to assist either on GitHub or on Discord with the implementation of this feature request.

Just letting you know.
We've change our approach. Instead of adding a Springwolf annotations to the classes/methods we've implemented the scanners interfaces to include our custom annotations.
Unfortunately the solution is strictly our product-oriented, so it's not suitable for contribution to Springwolf project.
Therefore, we do not plan to make development in this area (at least for now). Thanks for your help!

Thank you for the update @madrimas .

We also gather info about who is using Springwolf. Please comment your company's name in https://github.com/springwolf/springwolf-core/issues/342 - if you can.

Implemented as part of https://github.com/springwolf/springwolf-core/pull/964


Bug: Scan View Freezes

Campus mobile app, scan feature.
For every scan, need to go to previous page and come back and scan again

I can only reproduce this behavior on iPhone devices running build 51 from test flight.
Steps to reproduce:
Open app and log in
Go to scanner view
While in scanner view exit app (without closing fully)
Resume application and see that camera is frozen
Notes:
When camera freezes user is still able to submit text that was previously on screen.
User has to navigate back to the home screen and then re-enter the scan view in order to scan another code.
The app can scan multiple codes without having to navigate back to the home screen if the freezing does not occur.

can not reproduce on latest build in experimental-v2 branch

Cannot reproduce