HelmRelease targetNamespace not honored by helm release secret

I have noticed a strange behavior when using the targetNamespace feature of the HelmRelease.
My understanding was that installing a HelmRelease resource in targetNs or installing it in hrNs with targetNamespace targetNs should result in the same behavior from helm's point of view, with the only change being in where the helm-controller stores metadata to manage the reconciliation.
However I am seeing that when installing a HelmRelease in hrNs with targetNamespace targetNs, helm is somehow set up to store the release's secrets in hrNs rather than targetNs even though the release indeed targets targetNs.
This results in the weird behavior of that helm release not showing up when running helm list in targetNs but showing up with a different namespace when running helm list in hrNs as follows (output is simplified for better understanding):
$ helm list -n targetNs
NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION

$ helm list -n hrNs
NAME                            NAMESPACE       REVISION        UPDATED                                 STATUS        CHART                    APP VERSION
helmRelease                     hrNs            6               2020-12-28 16:47:12.134388 -0600 CST    deployed      helmRelease-0.0.12
helmRelease2                    hrNs            4               2020-12-22 15:31:46.448803 -0600 CST    deployed      helmRelease2-0.1.0
fluxRelease                     targetNs        14              2020-12-28 21:56:58.786390024 +0000 UTC deployed      fluxRelease-0.7.4

In the previous example, the two helmRelease helm releases are manually installed via helm while fluxRelease has been installed by the helm-controller.
This behavior also brings as consequence the fact that if fluxRelease had already been manually installed via helm and/or previously managed by helm-operator, when helm-controller starts the reconciliation process for the first time it believes that it is not yet installed (since the secret would live in targetNs and therefore it tries to do an install which might leave everything in a weird state considering the release already exists.
This behavior, as far as I have found, is also hard to reproduce using helm directly, as I don't see any option to install a release storing its secret in a different namespace, which might beg the question whether it will actually even remain supported by helm.
I think the reason for this is the initialization of the helm client here using the namespace of the HelmRelease rather than the targetNamespace.
Is this behavior intended? If so, is it officially supported by helm and do you have any advice on how to migrate a helm release already installed without having to purge it and re-install it?

It is intentional, there is some discussion in #96. I also recall some discussion about wanting to implement a flag for this upstream in the Helm CLI, but can't find that.

It is intentional, there is some discussion in #96. I also recall some discussion about wanting to implement a flag for this upstream in the Helm CLI, but can't find that.

@seaneagan Thank you for the info!
The issue I see with this approach is that, besides not being able to manually upgrade the helm release as mentioned in the discussion you linked, the targetNamespace used to work differently with helm-operator. Therefore, if users are migrating from helm-operator using targetNamespace to helm-controller, the migration guide is no longer valid.
Is there any plan to possibly make the storage namespace for targetNamespace configurable?
And is there any official guide/advice for this specific migration?

@seaneagan Thank you for the info!
The issue I see with this approach is that, besides not being able to manually upgrade the helm release as mentioned in the discussion you linked, the targetNamespace used to work differently with helm-operator. Therefore, if users are migrating from helm-operator using targetNamespace to helm-controller, the migration guide is no longer valid.
Is there any plan to possibly make the storage namespace for targetNamespace configurable?
And is there any official guide/advice for this specific migration?

I just stumbled upon that in combination with kubeConfig by trying to deploy a HelmRelease on another cluster. It fails because the namespace where the HelmRelease is applied does not exist on the remote cluster. This breaks the remote cluster ability.
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: my-chart
  namespace: local-namespace
spec:
  interval: 5m
  releaseName: my-chart
  targetNamespace: default
  kubeConfig:
    secretRef:
      name: kubeconfig
  chart:
    spec:
      chart: my-chart
      version: 1.0.0
      sourceRef:
        kind: HelmRepository
        name: my-repo
        namespace: flux-system

{"level":"error","ts":"2021-01-07T22:49:05.248Z","logger":"controller","msg":"Reconciler error","reconcilerGroup":"helm.toolkit.fluxcd.io","reconcilerKind":"HelmRelease","controller":"helmrelease","name":"my-chart","namespace":"local-namespace","error":"Helm install failed: create: failed to create: namespaces \"local-namespace\" not found"}

I just stumbled upon that in combination with kubeConfig by trying to deploy a HelmRelease on another cluster. It fails because the namespace where the HelmRelease is applied does not exist on the remote cluster. This breaks the remote cluster ability.
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: my-chart
  namespace: local-namespace
spec:
  interval: 5m
  releaseName: my-chart
  targetNamespace: default
  kubeConfig:
    secretRef:
      name: kubeconfig
  chart:
    spec:
      chart: my-chart
      version: 1.0.0
      sourceRef:
        kind: HelmRepository
        name: my-repo
        namespace: flux-system

{"level":"error","ts":"2021-01-07T22:49:05.248Z","logger":"controller","msg":"Reconciler error","reconcilerGroup":"helm.toolkit.fluxcd.io","reconcilerKind":"HelmRelease","controller":"helmrelease","name":"my-chart","namespace":"local-namespace","error":"Helm install failed: create: failed to create: namespaces \"local-namespace\" not found"}

@CuBiC3D I am running into the exact same issue with remote clusters.
@tommasopozzetti similar to you I found that it is the helm client config code that is problematic.
For remote users it is a pretty limiting factor because that code is essentially stripping any ability to set the storage namespace. In comparison, with raw helm it defaults to the namespace used in my config so I can at least implicitly set it.
I see a few possible solutions:

Let's treat targetNamespace as the namespace for both storage and manifests (the same way helm treats --namespace)
Don't override the namespace at all and instead use the namespace on the remote kubeconfig (the same way the helm docs recommend today)
Let's expose a second property on the HelmRelease called storageNamespace and let users pick their preferred storageNamespace

As I read through the code, I don't see any glaring reasons why we couldn't configure the storageNamespace since:

The runner is instantiated for every reconcile (allowing HelmReleases to have different storageNamespaces)
The runner seems to be nicely designed as the single layer for working with Helm therefore making the code change pretty clean

Tagging those who seem like they have interest / knowledge based on #96
@seaneagan @hiddeco
Also, happy to contribute code to any solutions

@CuBiC3D I am running into the exact same issue with remote clusters.
@tommasopozzetti similar to you I found that it is the helm client config code that is problematic.
For remote users it is a pretty limiting factor because that code is essentially stripping any ability to set the storage namespace. In comparison, with raw helm it defaults to the namespace used in my config so I can at least implicitly set it.
I see a few possible solutions:

Let's treat targetNamespace as the namespace for both storage and manifests (the same way helm treats --namespace)
Don't override the namespace at all and instead use the namespace on the remote kubeconfig (the same way the helm docs recommend today)
Let's expose a second property on the HelmRelease called storageNamespace and let users pick their preferred storageNamespace

As I read through the code, I don't see any glaring reasons why we couldn't configure the storageNamespace since:

The runner is instantiated for every reconcile (allowing HelmReleases to have different storageNamespaces)
The runner seems to be nicely designed as the single layer for working with Helm therefore making the code change pretty clean

Tagging those who seem like they have interest / knowledge based on #96
@seaneagan @hiddeco
Also, happy to contribute code to any solutions

The feature was initially aimed at multi-tenancy where "something" would be injected into the tenants namespace, and hiding the storage from the tenant made sense for this. Since the introduction of the KubeConfig feature, and because people at times seem to have other use-cases and/or structural setups, this seems to be a limitation.
To offer full flexibility, I think

Let's expose a second property on the HelmRelease called storageNamespace and let users pick their preferred storageNamespace

is a great idea, but in a way that is backwards compatible.

The feature was initially aimed at multi-tenancy where "something" would be injected into the tenants namespace, and hiding the storage from the tenant made sense for this. Since the introduction of the KubeConfig feature, and because people at times seem to have other use-cases and/or structural setups, this seems to be a limitation.
To offer full flexibility, I think

Let's expose a second property on the HelmRelease called storageNamespace and let users pick their preferred storageNamespace

is a great idea, but in a way that is backwards compatible.

Put up a draft PR to add the property. It is optional so I think it should maintain backwards compatibility while extending the functionality.
Would love some input and if everyone is happy with the approach I can add some tests
#198

Put up a draft PR to add the property. It is optional so I think it should maintain backwards compatibility while extending the functionality.
Would love some input and if everyone is happy with the approach I can add some tests
#198

@gtracer I think this would be a perfect solution, solving all issues reported up to now here and maintaining backwards compatibility for current users.
I would suggest also changing the docs around helm-operator to helm-controller migration to point out that if users are using helm-operator with helmreleases.helm.fluxcd.io/v1 exploiting the targetNamespace feature, they should convert those to helmreleases.helm.toolkit.fluxcd.io/v2beta1 setting both targetNamespace and storageNamespace to the same namespace in order to maintain the same behavior.

@gtracer I think this would be a perfect solution, solving all issues reported up to now here and maintaining backwards compatibility for current users.
I would suggest also changing the docs around helm-operator to helm-controller migration to point out that if users are using helm-operator with helmreleases.helm.fluxcd.io/v1 exploiting the targetNamespace feature, they should convert those to helmreleases.helm.toolkit.fluxcd.io/v2beta1 setting both targetNamespace and storageNamespace to the same namespace in order to maintain the same behavior.

Available in helm-controller v0.6.1 and flux v0.7.0.

Available in helm-controller v0.6.1 and flux v0.7.0.


Include example of regex syntax

It took me some time to figure out the exact regex syntax, so I thought it could be worth mentioning in the docs since there are so many different regex implementation in different languages. It also seems like the syntax has changed somewhat and no longer requires the backslashes mentioned in https://github.com/retorquere/zotero-better-bibtex/issues/1933#issuecomment-973360959).
Maybe there could also be a section somewhere in the docs with more advanced examples? E.g. I use the following to include only one author if there is only one, and if there is more than one I include first and last author:

(
    authorsn(sep=';').replace(/[^;]/g, '').len('>',0)
    ? authorLast.lower.postfix("\_")+auth.lower.postfix("\_")
    : auth.lower.postfix("\_")
)
+year.postfix("\_")
+shorttitle(2).condense('\-').lower()

Thank you, I agree that a link to a more encompassing guide is great and didn't realize that these were JS regexes. The doc page you suggested is helpful imo; it shows both the g flag and the negation pattern early on in the guide. I replaced my example with that link.

Thanks for the contribution!


Pass all files other then node_modules though babel loader by default

Issue: https://github.com/storybooks/storybook/issues/6047
What I did
REMOVE the include lists for the babel-loader, this should enable transpiling for files
other then in your source directory, making the need for custom webpack configs less prominent.
ADD a thread-loader to hopefully speed up the building of large storybooks.
ADD a loader for css and a file-loader for other files.
Storybook will now transpile all files through babel as long as /node_modules/ doesn't exists in the file's path.
This is a breaking change
This makes it easier for users to write their addons locally and have them be transpiled by webpack/babel.
UPGRADE to core-js 3
REMOVE alias for core-js
CHANGE transpile strategy: transpile to ES modules for better tree-shaking.

@ndelangen This seems like a massive change. Can we postpone it until 5.2?

@shilman Yes I know this is massive. Might be 6.0 material..


rez env with an escaped > symbol in a package requirement still redirects stdout on Windows

Cannot test this on Linux, but on Windows it's certainly an issue.
Because Rez requirements can include the < and > stream redirection characters, obviously there's a problem if these are not escaped in the shell when passed to Rez:
rez env python>2.7.11

The above will run "rez env python" and pipe all output to a new file "2.7.11" ... the actual version requirement is lost. So of course the user must run the escaped version, which on Windows uses the ^ char:
rez env python^>2.7.11

This actually works and the Rez configured environment does pick up ie 2.7.12 (or fails if no greater version than 2.7.11 is installed) ... however it still creates the "2.7.11" file.
That tends to indicate that it's either happening in a Python subprocess call (where the unescaped arg is being passed and shell=True), or it's happening in the compiled shell code.  Having a hell of a time finding where or which it is.

Hah! Just found it.  The compiled shell code includes a section that sets the REZ_USED_REQUEST env var to the exact string value received ... that then runs "set REZ_USED_REQUEST=python>2.7.11", and as that's run as an individual command it redirects the STDOUT of the set command to that file, creating the new file in the process.
That also explains why an escaped < char results in a "The system cannot find the file specified" message when the file being redirected to stdin doesn't exist.
The other implication is that something similar could happen with the "implicit_packages" variable in rez_config.py, as you can set soft requirements with the > and < chars there as well.
Well, at least I know where it is.  I'll see if I can find time to dig in and fix.
M

Mm, is this actually a case of Rex not escaping the string?
You can test this with the rez-interpret tool:
in test.rex
env.FOO = 'bah>5.4'
]$ rez-interpret test.rex --format bash
export FOO="bah>5.4"
Presumably the same codepath for Windows is not escaping that output
correctly.
A
On Wed, Aug 24, 2016 at 11:29 AM, Michael Morehouse <
<EMAIL_ADDRESS>wrote:

Hah! Just found it. The compiled shell code includes a section that sets
the REZ_USED_REQUEST env var to the exact string value received ... that
then runs "set REZ_USED_REQUEST=python>2.7.11", and as that's run as an
individual command it redirects the STDOUT of the set command to that file,
creating the new file in the process.
That also explains why an escaped < char results in a "The system cannot
find the file specified" message when the file being redirected to stdin
doesn't exist.
The other implication is that something similar could happen with the
"implicit_packages" variable in rez_config.py, as you can set soft
requirements with the > and < chars there as well.
Well, at least I know where it is. I'll see if I can find time to dig in
and fix.
M
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nerdvegas/rez/issues/342#issuecomment-242163947, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABjqSmUSznkssXpfJkAmX_DQ4EN4qM4Oks5qjI17gaJpZM4JsTUY
.

Yeah, I think I found it, the escape_string method currently does nothing. Working on a merge request.
M
On Aug 24, 2016, 12:22 -0700, allan johns<EMAIL_ADDRESS>wrote:

Mm, is this actually a case of Rex not escaping the string?
You can test this with the rez-interpret tool:
in test.rex
env.FOO = 'bah>5.4'
]$ rez-interpret test.rex --format bash
export FOO="bah>5.4"
Presumably the same codepath for Windows is not escaping that output
correctly.
A
On Wed, Aug 24, 2016 at 11:29 AM, Michael Morehouse <
<EMAIL_ADDRESS>wrote:

Hah! Just found it. The compiled shell code includes a section that sets
the REZ_USED_REQUEST env var to the exact string value received ... that
then runs "set REZ_USED_REQUEST=python>2.7.11", and as that's run as an
individual command it redirects the STDOUT of the set command to that file,
creating the new file in the process.
That also explains why an escaped < char results in a "The system cannot
find the file specified" message when the file being redirected to stdin
doesn't exist.
The other implication is that something similar could happen with the
"implicit_packages" variable in rez_config.py, as you can set soft
requirements with the > and < chars there as well.
Well, at least I know where it is. I'll see if I can find time to dig in
and fix.
M
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nerdvegas/rez/issues/342#issuecomment-242163947, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABjqSmUSznkssXpfJkAmX_DQ4EN4qM4Oks5qjI17gaJpZM4JsTUY
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub (https://github.com/nerdvegas/rez/issues/342#issuecomment-242179069), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAnEp_Y18ESZkWkcUkPV9hdrqih495xAks5qjJn4gaJpZM4JsTUY).

This is now addressed in #341.


Uncaught RangeError: Maximum call stack size exceeded

[Enter steps to reproduce below:]

...
...

Atom Version: 1.7.3
System: linux 4.5.1-1-ARCH
Thrown From: nvatom package, v0.10.0
Stack Trace
Uncaught RangeError: Maximum call stack size exceeded
At /home/bulbil/.atom/packages/nvatom/node_modules/docquery/node_modules/lunr/lunr.js:968

RangeError: Maximum call stack size exceeded
    at [object Object].<anonymous> (/home/bulbil/.atom/packages/nvatom/node_modules/docquery/node_modules/lunr/lunr.js:968:34)
    at Array.forEach (native)
    at [object Object].lunr.Index.add (/home/bulbil/.atom/packages/nvatom/node_modules/docquery/node_modules/lunr/lunr.js:964:16)
    at DocQuery.addDocument (/home/bulbil/.atom/packages/nvatom/node_modules/docquery/lib/DocQuery.js:85:24)
    at FSWatcher.<anonymous> (/home/bulbil/.atom/packages/nvatom/node_modules/docquery/lib/DocQuery.js:63:13)
    at emitTwo (events.js:87:13)
    at FSWatcher.emit (events.js:172:7)
    at FSWatcher.<anonymous> (/home/bulbil/.atom/packages/nvatom/node_modules/chokidar/index.js:171:15)
    at FSWatcher._emit (/home/bulbil/.atom/packages/nvatom/node_modules/chokidar/index.js:212:5)
    at FSWatcher.NodeFsHandler._handleFile (/home/bulbil/.atom/packages/nvatom/node_modules/chokidar/lib/nodefs-handler.js:275:10)
    at FSWatcher.<anonymous> (/home/bulbil/.atom/packages/nvatom/node_modules/chokidar/lib/nodefs-handler.js:473:21)
    at FSReqWrap.oncomplete (fs.js:82:15)

Commands
     -0:04.1.0 nvatom:toggle (atom-pane.pane.active)

Config
{
  "core": {
    "themes": [
      "arc-darker"
    ]
  },
  "nvatom": {
    "directory": "~/Dropbox/notational"
  }
}

Installed Packages
# User
nvatom, v0.10.0

# Dev
No dev packages

I think there is some infinite recursive call somewhere, but with this info, it is hard to figure out what is wrong... How is the file/directory structure is? Do you have symbolic links?


[$500] Public room - Sign-in modal is hidden behind welcome modal after selecting an option

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.31-2
Reproducible in staging?: y
Reproducible in production?: new feature
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause internal team
Slack conversation:
Action Performed:

Log out if logged in.

Navigate to public room https://staging.new.expensify.com/r/2376199970894587

Select any option in the welcome message modal.

Expected Result:
Welcome modal will dismiss and sign-in modal will appear after selecting an option.
Actual Result:
The link changes to sign-in URL, but the welcome modal does not dismiss and the sign-in modal is hidden behind it.
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/43996225/eb1acbbb-aa70-4234-81e9-bb7a4b5cd596

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01bdb196958ade050b
Upwork Job ID:<PHONE_NUMBER>444123136
Last Price Increase: 2024-02-13

Proposal
Please re-state the problem that we are trying to solve in this issue.
Sign-in modal is hidden behind welcome modal after selecting an option in public room
What is the root cause of that problem?
We have recently introduced full screen engagement modal named PurposeForUsingExpensifyModal
We pass onPress handler to the MenuItem here
https://github.com/Expensify/App/blob/0d0b0a8c9b073c30a9b54de15066789d17f7c718/src/components/PurposeForUsingExpensifyModal.tsx#L123
When selecting an option, we redirect to the sign-in modal if the user is not signed in
https://github.com/Expensify/App/blob/0d0b0a8c9b073c30a9b54de15066789d17f7c718/src/components/MenuItem.tsx#L381
https://github.com/Expensify/App/blob/0d0b0a8c9b073c30a9b54de15066789d17f7c718/src/libs/actions/Session/index.ts#L134-L139
So menu item's onPress handler isn't executed at all.
This is the root cause
What changes do you think we should make in order to solve the problem?
We can listen navigation state and hide the engagement modal if needed
We show this modal on mount here
https://github.com/Expensify/App/blob/0d0b0a8c9b073c30a9b54de15066789d17f7c718/src/components/PurposeForUsingExpensifyModal.tsx#L91-L101
We can add navigation listener here
    useEffect(() => {
        ~  ~  ~
        Welcome.show(routes, () => setIsModalOpen(true));
        return navigation.addListener('state', (event) => {
            const state = event.data.state;
            const route = state.routes[state.index];
            if (route.name === currentRoute.name) {
                return;
            }
            setIsModalOpen(false);
        });
        // eslint-disable-next-line react-hooks/exhaustive-deps
    }, []);

We compare the route's name to determine if we need to hide the modal in the above solution. We can use more optimized or suitable comparison
The solution works as expected

Result
https://github.com/Expensify/App/assets/126839717/277fb14b-3d6a-4a87-9792-bf59e2485628

What alternative solutions did you explore? (Optional)

Interesting - will wait to let @stitesExpensify chime in. We'll definitely want to fix this soon, though I don't think this needs to block deploy. This relies on engaging with us from a public room and if you dismiss the screen you'll see the sign in screen

@MitchExpensify what do you think the intended functionality should be here? I'm thinking that we don't show the engagement modal at all to anonymous users both before and after they sign in. Thoughts?

I'm thinking that we don't show the engagement modal at all to anonymous users both before and after they sign in. Thoughts?

For sure, yes! Lets not show the modal to anonymous users before they sign in

Issue not reproducible during KI retests. (First week)

I closed it because QA reported it as not reproducible.

Asking for re-test

Seeing Sign in modal now https://github.com/Expensify/App/assets/43995119/23f1ad8c-fde5-4435-8245-a96f6a97e551

and on Web
https://github.com/Expensify/App/assets/43995119/39deff4c-bb73-44ae-aa2e-42b38c7a1e96

Cool I'll reopen then.

Proposals still in review

Heads up I just made this external again because I have higher priority issues that I need to work on and it seems like we are close to a solution. @fedirjh can you please address the comments above from @dukenv0307? Thanks everyone.

Is this issue open to proposals ?

Bump @fedirjh

It's a personal policy that gets returned. I am not familiar with how anonymous accounts work so it would be good to get @marcochavezf's opinion here.
I want to say that anonymous accounts can't really do much - like anything you'd need a personal policy for - you probably can't do, but there is probably some reason it is included that we are not seeing.

Every account is created with a personal policy, including anonymous accounts since they're regular accounts with some restrictions. What problem is causing the anonymous account's personal policy?

The conversation about not sending the personal policy from the backend has confused everything a bit. If the end goal is that we don't want to show this modal for anonymous users then we can just check if they are an anonymous user and then don't show the modal. Assigning @dukenv0307.

Do not show engagement modal for anonymous users, we can update here to early return if Session.isAnonymousUser() is true

Let's just do this.

or we can connect to the SESSION key to the BottomTabBar and use the session?.authTokenType to detect anonymous user, to make sure the block is rerun again when the session auth type changes.

What is the advantage of doing this? Let's do the first one I think.

If we don't want to show the engagement modal even after the anonymous user logs in, we can make sure to set isFirstTimeNewExpensifyUser to true and send back from the back-end after the user signs in successfully. Or we can do this in client side (if the user is anonymous) when the user begins the sign in API request in optimisticData and successData.

👎  - I don't really understand what problem we are trying to solve. Let's fix "sign in modal is hidden behind welcome modal".

If instead we want to show the engagement modal after the anonymous user logs in, we have to make sure to remove the policies of the anonymous user in successData after the the user signs in (or the back-end can clear it in Onyx data when returning response). So that this logic will work correctly, otherwise there'll be 2 policies (1 of the signed in user and 1 of the anonymous user) and the engagement modal will not show.

Again - not too sure what problem we are trying to solve. We agreed to not show them this modal.

Issue not reproducible during KI retests. (Second week)

Bumping this one.

Sorry for the delay here, all set.


chore(docs): update docs to match new contarct expectations for write…

…s using mIO
The contract is moving towards only supporting mIO for write interactions. We will update the docs to match, and in the next version require mIO token for write interactions.
Related change: https://github.com/ar-io/testnet-contract/pull/245

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

Project coverage is 78.30%. Comparing base (911b02b) to head (b18352d).
Report is 42 commits behind head on alpha.

Additional details and impacted files
@@            Coverage Diff             @@
##            alpha      #90      +/-   ##
==========================================
- Coverage   80.86%   78.30%   -2.56%
==========================================
  Files          19       20       +1
  Lines         465      530      +65
  Branches       95      102       +7
==========================================
+ Hits          376      415      +39
- Misses         85      109      +24
- Partials        4        6       +2

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


Chainverseos v2 serach full text

What changed

How did you test the change?

This is awesome! What would it take to change  the "more results" with some sort of loading icon? Like the Diamond DAO logo + ...?


[Feature]  Enhanced horizontal scaling of app controller

Is your feature request related to a problem? Please describe.
Due to the leader-election of the controller, when there are thousands of application CRs in the hubcluster,
the new application will be delayed for updating longer and longer time.
Describe the solution you'd like
For this issue, i have made some experimental solution.
We want to dispatch several deployment of app controller in hubcluster.
Firstly, enabling the leader election and set leader-election-resource-name with different name e.g sharding-1, sharding-2.
Secondly, we add a label tag for every application CR, e.g app.oam.dev/sharding=sharding-1
Thirdly, add a filter to controller's eventFilter. Only the value of label tag is equal to leader-election-resource-name, the controller will handle the application CR.
The final effect is: application CR with label value of sharding-1 will only be processed by app controller with leader-selection-resource-name value of sharding-1

Great! This solution looks good and is similar to what I have been thinking for sharding. Would you like to make a PR for that?

Great! This solution looks good and is similar to what I have been thinking for sharding. Would you like to make a PR for that?

Of course, i will make a PR.

lgtm

Just FYI, there's another solution for this issue, which don't need change the controller code: https://github.com/openkruise/controllermesh

Sharding is supported now, please check https://github.com/kubevela/kubevela/pull/5360
It will be released in 1.8.0 and you can already enjoy this feature in https://github.com/kubevela/kubevela/releases/tag/v1.8.0-alpha.1
Closing


Reload Fails Due to the Recurrence Table Missing

Downloaded this app a couple months ago and had it running with no problems until this last week.
The reload started to fail and when I investigated it seems it was Due to the Recurrence Table not being found. After forcing through the error I also notice an error about the field "_AuditReloadKey" Field not being found which broke all the mappings later in the code.
I was confused because it was working well before and just stopped recently, nothing was changed from my knowledge.

Fixed the issue by grabbing an updated version of the application.


Stream inspector for destinations

Description
Depends on #732
Fixes #700
Quick checks:

[x] I have followed the Code Guidelines.
[x] There is no other pull request for the same update/change.
[x] I have written unit tests.
[x] I have made sure that the PR is of reasonable size and can be easily reviewed.

@lovromazgon Thanks for the great review as always!

* Stopping Conduit with an inspector is not possible, Conduit blocks until the client closes the connection.

I'll check that. :+1:

* It's possible to start an inspector on a stopped pipeline, we should probably check the status and return an error if that's the case.

* Similarly it's possible to stop a pipeline and keep an inspector running, I'd also expect the inspector to stop in that case.

Actually, that was done intentionally. By making it possible to start the inspector before the pipeline, you can get all the records from the pipeline. If it's required to start the pipeline first, and then the inspector, it's possible to miss some records.
Similarly for stopping the inspector when the pipeline is stopped. This way it's possible to restart a pipeline while troubleshooting and not miss anything.

* While testing I was able to process up to 120 records per second (I used https://websocketking.com/), that feels a bit slow given that it's running on the same machine, am I expecting too much?

When you say "up to 120 records per second", does that mean when the record rate is higher, records start being dropped?

* I don't think we mentioned metrics in the design, but I think it would be nice to at least see the number of open inspector sessions on a connector / processor. WDYT? No need to do it in this PR.

I like that suggestion, I opened an issue for it now #742.

Stopping Conduit with an inspector is not possible, Conduit blocks until the client closes the connection.

I've just re-tested this, with 1000 msg/s, and five inspectors. I stopped Conduit and it stopped w/o a problem. The inspector sessions got closed too, and that's the same I've been always seeing. But I was running and stopping Conduit through GoLand, stopping it with Ctrl+C through the command line reproduces the issue.:)

It's possible to start an inspector on a stopped pipeline /.../ Similarly it's possible to stop a pipeline and keep an inspector running

Actually, that was done intentionally.

Alright, but then we have to be careful what happens if the connector gets deleted while it has an active inspector session.

When you say "up to 120 records per second", does that mean when the record rate is higher, records start being dropped?

Initially no, because of the buffer, but if that rate would persist it would probably happen. I'm saying that I see records arriving in the client about every 0.01 seconds (a bit less). My expectation was that a websocket should be able to handle more, but here we have the grpc-gateway in between which maybe affects the performance.

I was running and stopping Conduit through GoLand, stopping it with Ctrl+C through the command line reproduces the issue.

Yes, that's what I mean. Looks like GoLand does something differently (kills the process?).

Alright, but then we have to be careful what happens if the connector gets deleted while it has an active inspector session.

True. :+1: WDYT about handling that separately? I feel it's not something which happens that often (someone inspecting a pipeline and someone else deleting a connector at the same time).

Initially no, because of the buffer, but if that rate would persist it would probably happen. I'm saying that I see records arriving in the client about every 0.01 seconds (a bit less). My expectation was that a websocket should be able to handle more, but here we have the grpc-gateway in between which maybe affects the performance. Maybe it's also that websocketking is the cause, can you tell me what you're using for testing?

I've been using wscat (a CLI tool). I noticed that the WebSocket King client prints timestamps with a 0.01s precision. I ran Conduit with 1000 msg/s and connected to an inspector using wscat and WebSocket King, and I didn't see the log message about records being dropped even after it's been running for some time.

WDYT about handling that separately?

I think as long as deleting a connector while an inspector is running doesn't crash Conduit it's fine to tackle it separately 👍

I've been using wscat (a CLI tool).

I need to try that!
Let me clarify again what I mean by those 120 records per second. I created a pipeline reading from a file and writing to another file, then opened an inspector with WebSocket King, then wrote 120 lines in the first file. I see records appear almost instantly in the target file, but I can watch the websocket client loading the records, it takes it about 1 second to stop loading them. I know, not a very precise approach, and it doesn't tell me where the bottlenecks sits, but it did cause me to raise my eyebrow 🤨

I think as long as deleting a connector while an inspector is running doesn't crash Conduit it's fine to tackle it separately +1

I've checked that, and Conduit continues running. I've created an issue for this: #743.


Use Trackpad Scroll Emulator for better scrollbars

I ended up implementing this because it would take a lot of work to explain.
My primary objective was to eliminate native scrollbar from table body.
I also ended up addressing a problem with table heights. Previously table heights were set on t.body which was weird to style because you needed to manually consider the height of footer and header. The improved implementation uses Flexbox to automatically calculate table body taking into consideration header and footer.
I removed table-scroll mixin in favour of scrolling mechanism provided by Trackpad Scroll Emulator. I don't think TSE's mechanism is better but we don't need two versions of the same functionality.
I added several dependencies:

ember-composable-helper - provides pipe and compute helpers
ember-scrollable - provides TSE and as-scrollable component

Awesome work @taras! Thank you! 😺


Install fonts from xmlrfc-fonts repository

Description
Install fonts from xml2rfc-fonts.
Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

I have created this on the wrong repository.


The latest jf-cli has not been updated in Debian(ubuntu22), it currently still 2.59.1

I am unable to install the latest version by using apt install on Ubuntu22, and its latest version is still 2.59.1. and I need to use version 2.61+ in Debian

Hi @kunkka-m
Thanks for reporting this issue.
Can you confirm that it's still happening with the latest 2.63 version?

Hi @sverdlov93
I got the rc, This may be caused by an internal JFrog configuration issue, using the official repo will works.

So no issue here for 2.60+ versions on our side?

Yes, thanks!


[WIP] Migrating Seeding Over to yml

Converts miq_event_definition_sets.csv and miq_event_definitions.csv to yml

@DavidResende0 Can you add the deleting of the .csv to this PR as well?  I have a feeling something else is reading it, and if you delete it we'll quickly find out

@DavidResende0 Can you add the deleting of the .csv to this PR as well?  I have a feeling something else is reading it, and if you delete it we'll quickly find out

The problem is that the test itself is stubbing out a fake CSV file for verifying seeding. You're going to have to update the test itself
https://github.com/ManageIQ/manageiq/blob/5cf86404a67869bdb62a7d86811105c6c6492d92/spec/models/miq_event_definition_spec.rb#L31-L37

The problem is that the test itself is stubbing out a fake CSV file for verifying seeding. You're going to have to update the test itself
https://github.com/ManageIQ/manageiq/blob/5cf86404a67869bdb62a7d86811105c6c6492d92/spec/models/miq_event_definition_spec.rb#L31-L37

So I'm running into this error when running miq_event_definition_spec.rb
Failure/Error: expect(event_def.memberof).to eq [set2]
       expected: [#<MiqEventDefinitionSet id:<PHONE_NUMBER>0627, name: "evm_operations", description: "Evm operations", s...ad_only: nil, set_data: nil, mode: nil, owner_type: nil, owner_id: nil, userid: nil, group_id: nil>]
            got: []
       (compared using ==)
       Diff:
       @@ -1 +1 @@
       -[#<MiqEventDefinitionSet id:<PHONE_NUMBER>0627, name: "evm_operations", description: "Evm operations", set_type: "MiqEventDefinitionSet", created_on: "2021-01-25 21:41:38", updated_on: "2021-01-25 21:41:38", guid: "260daa33-79ee-4116-b4b5-b2b826a26fe1", read_only: nil, set_data: nil, mode: nil, owner_type: nil, owner_id: nil, userid: nil, group_id: nil>]
       +[]
     # ./spec/models/miq_event_definition_spec.rb:71:in `block (8 levels) in <top (required)>'

After doing some digging I can see that the issue is that the second event_definitions isn't being placed into set 2 https://github.com/ManageIQ/manageiq/blob/be500e9357a2894996b1b8ca9d179a4b3f07429b/spec/models/miq_event_definition_spec.rb#L52-L72
Failure/Error: raise event_def.memberof.to_s
     RuntimeError:
       []

Anyone know if this is an issue with miq_event_definition.rb or miq_event_definition_spec.rb?

So I'm running into this error when running miq_event_definition_spec.rb
Failure/Error: expect(event_def.memberof).to eq [set2]
       expected: [#<MiqEventDefinitionSet id:<PHONE_NUMBER>0627, name: "evm_operations", description: "Evm operations", s...ad_only: nil, set_data: nil, mode: nil, owner_type: nil, owner_id: nil, userid: nil, group_id: nil>]
            got: []
       (compared using ==)
       Diff:
       @@ -1 +1 @@
       -[#<MiqEventDefinitionSet id:<PHONE_NUMBER>0627, name: "evm_operations", description: "Evm operations", set_type: "MiqEventDefinitionSet", created_on: "2021-01-25 21:41:38", updated_on: "2021-01-25 21:41:38", guid: "260daa33-79ee-4116-b4b5-b2b826a26fe1", read_only: nil, set_data: nil, mode: nil, owner_type: nil, owner_id: nil, userid: nil, group_id: nil>]
       +[]
     # ./spec/models/miq_event_definition_spec.rb:71:in `block (8 levels) in <top (required)>'

After doing some digging I can see that the issue is that the second event_definitions isn't being placed into set 2 https://github.com/ManageIQ/manageiq/blob/be500e9357a2894996b1b8ca9d179a4b3f07429b/spec/models/miq_event_definition_spec.rb#L52-L72
Failure/Error: raise event_def.memberof.to_s
     RuntimeError:
       []

Anyone know if this is an issue with miq_event_definition.rb or miq_event_definition_spec.rb?

@DavidResende0 I think what's happening is that the inner let(:event_definitions) is overriding the outer one.  This happens before any code is run, so when you run the first seed here, it's actually seeding with the "new" values instead.  Then the second seed is a no-op because it's also using the "new" values.  Not 100% sure, but one of the advantages of nesting lets is allowing you to override values, so this is like an unfortunate side effect of that.
To fix you might just want to rename the inner one to something like "new_event_definitions"

@DavidResende0 I think what's happening is that the inner let(:event_definitions) is overriding the outer one.  This happens before any code is run, so when you run the first seed here, it's actually seeding with the "new" values instead.  Then the second seed is a no-op because it's also using the "new" values.  Not 100% sure, but one of the advantages of nesting lets is allowing you to override values, so this is like an unfortunate side effect of that.
To fix you might just want to rename the inner one to something like "new_event_definitions"

Sorry, I didn't see this update.  LGTM.  I'm concerned with the existing data.  Have this been tested in the following scenarios:

Empty DB before this PR and empty DB after this PR.  Do the table rows match 100%?
Existing DB with previously seeded rows: does it consistently find/update the existing rows in the same way as it did prior to this PR?

The code changes look good but I have no reviewed the csv to yaml changes to check if they're 100% identical but just in a different format.  I think those scenarios would verify that beyond what the unit tests do.


How to configure NLog in MVC6

How to configure NLog in MVC6

I think you need:  https://github.com/NLog/NLog.Extensions.Logging/
NB: .Net Core RC2 Is not supported yet.

Thanks. working fine

:+1:


Ignore Strong references

I need to handle when strongs references are in \wj:

\v 3  \wj “+w Blessed|strong="G3107"+w* +w are|strong="G1510"+w* +w the|strong="G3588"+w* +w poor|strong="G4434"+w* +w in|strong="G4434"+w* +w spirit|strong="G4151"+w*,\wj*
\q2 \wj  +w for|strong="G3754"+w* +w theirs|strong="G0846"+w* +w is|strong="G1510"+w* +w the|strong="G3588"+w* +w Kingdom|strong="G0932"+w* +w of|strong="G0932"+w* +w Heaven|strong="G3772"+w*.\wj*\x + \xo 5:3  \xt Isaiah 57:15; 66:2\x*

@davidmoore1 I am asking on Proskomma Discord server if there is a better way to mutate the Proskomma data with GraphQL instead of filtering the text on the way in.

FYI: size difference
before: 8.1MB
after: 3.4MB


Nginx "core dumped"

Hello,
This happens upon loading the sample rules suggested in the CRS documentation.
Nginx is configured like this:
server {
        server_name georg.systems;
        modsecurity on;
        modsecurity_rules_file /etc/nginx/security/modsecurity_includes.conf;

        location / {
           <something>
        }
}

The includes file is filled according to to https://coreruleset.org/docs/deployment/install/#includes-for-nginx, except for the BEFORE/AFTER rules.
Upon trying to connect to the webserver as configured above the connection is aborted:
$ curl -I https://georg.systems/
curl: (92) HTTP/2 stream 1 was not closed cleanly before end of the underlying stream

And nginx's error.log reports the worker to have crashed:
2022/08/13 09:53:09 [notice] 6173#6173: signal 17 (SIGCHLD) received from 6940
2022/08/13 09:53:09 [alert] 6173#6173: worker process 6940 exited on signal 11 (core dumped)
2022/08/13 09:53:09 [notice] 6173#6173: start worker process 6950

ModSecurity's SecDebugLog stays empty, even with SecDebugLogLevel 9. I tested it with SecRuleEngine On as well as SecRuleEngine DetectionOnly.
The site is being served properly if I leave only the modsecurity.conf in the includes file.
Most setup options have been left at their defaults, the most I changed were the log and data storage paths.
Versions:
CRS: 3.3.2
ModSecurity: 3.0.7
ModSecurity-nginx: 1.0.3
Nginx: 1.23.1
OS: openSUSE Leap 15.4

nginx -V
nginx version: nginx/1.23.1
built by gcc 7.5.0 (SUSE Linux)
built with OpenSSL 1.1.1d  10 Sep 2019 (running with OpenSSL 1.1.1l  24 Aug 2021 SUSE release 1504<IP_ADDRESS>)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie'

The module was loaded dynamically.

Hello @tacerus ,
Are you using lmdb? If so, there is a known crash scenario if the file location is one that the process does not have sufficient permissions to write to. See https://github.com/SpiderLabs/ModSecurity/issues/2755. If that sounds like your situation, likely the simplest resolution is to use the nginx configuration item 'working_directory' (https://github.com/SpiderLabs/ModSecurity/issues/2755#issuecomment-1150059329).
If that is not your issue, then ...
The message about 'HTTP/2 stream 1' might be an indication that HTTP/2 is a factor in causing the problem. If so, you could try experimentally allowing only HTTP/1.1. On the other hand the HTTP/2 could be a merely consequence of the crash. Are you able to supply a stack trace from the core dump?

Hi @martinhsv, thank you for getting back!
I am not using lmdb, however I have compiled ModSecurity with lmdb support.
As for HTTP/2, I actually thought of that as well and did try to connect with curl's --http1.1 and --http1.0, which resulted in a slightly different client side error message (which I unfortunately not saved) but the same server side crash.
I now recompiled ModSecurity as well as the dynamic module without lmdb support - and I can no longer reproduce the worker crashes! I assume we can conclude it to #2755, which you linked, then? But if you'd like, I can try it again with lmdb and with nginx's --debug configure option to supply a stack trace!
Whilst my core dump issue is presumably solved now, I still have the issue with it not printing any log output:
SecRuleEngine On
SecDebugLog /var/log/nginx/modsecurity/debug.log
SecDebugLogLevel 9
SecAuditEngine On
SecAuditLogType Serial
SecAuditLogStorageDir /var/log/nginx/modsecurity/audit/

$ ls -al /var/log/nginx/modsecurity/
total 0
drwxr-xr-x 1 nginx root    28 Aug 13 09:42 .
drwxr-xr-x 1 root  root 10028 Aug 13 00:00 ..
drwxr-xr-x 1 nginx root     0 Aug 13 09:42 audit
-rw-r--r-- 1 nginx root     0 Aug 12 17:20 debug.log

Should I move this to a separate issue? I assume it's not related.

Hello @tacerus,
Given your use of italics ('using'), I'm assuming you mean that you don't care about using the functionality provided by lmdb. But of course if ModSecurity has been built with '--with-lmdb' and one or more relevant rules are triggered (which, as I recall, would likely be the case based on the rule set that you cited), the ModSecurity will use the lmdb. (That's probably understood by you but I thought I'd be explicit for anyone else reading this item.)
Note that for audit log, you have specified SecAuditLogStorageDir. However, that configuration item is relevant only if using SecAuditLogType Concurrent. Since you are using SecAuditLogType Serial , you need to use SecAuditLog for the audit log file location.
I have only ever seen failures to write to the debug log when there are permissions issues. If you want those particular locations, that's something you can check. (Incidentally, there is no need to pre-allocate the files yourself; ModSecurity will create them at the specified locations on startup if it has permissions to do so.)
I personally always use:
SecAuditLog /var/log/modsec_audit.log

and
SecDebugLog /var/log/modsec_debug.log

Actually, I did not realize some of my rules were utilizing lmdb! and I missed that SecAuditLogStorageDir was only compatible with SecAuditLogType Concurrent. Very helpful - thank you very much!!


[WFCORE-3069] More digest algorithms into OneTimePassword

Depends on https://github.com/wildfly-security/wildfly-elytron/pull/914 (reason of current build failures)
https://issues.jboss.org/browse/WFCORE-3069
https://issues.jboss.org/browse/JBEAP-12113

Core - Full Integration Build 5452 outcome was FAILURE using a merge of cad95609308a201aea8a24a517992aa5b63e576f
Summary: Compilation error: Compiler (new) Build time: 00:00:31

Full integration - Windows Build 3874 outcome was FAILURE using a merge of cad95609308a201aea8a24a517992aa5b63e576f
Summary: Compilation error: Compiler (new) Build time: 00:03:01

retest this please

Core - Full Integration Build 5458 outcome was FAILURE using a merge of cad95609308a201aea8a24a517992aa5b63e576f
Summary: Compilation error: Compiler Build time: 00:00:41

Full integration - Windows Build 3881 outcome was FAILURE using a merge of cad95609308a201aea8a24a517992aa5b63e576f
Summary: Compilation error: Compiler Build time: 00:02:31

(waiting for wildfly-elytron 1.1.0.CR3 tagging and upgrade)

Core - Full Integration Build 5466 outcome was FAILURE using a merge of cad95609308a201aea8a24a517992aa5b63e576f
Summary: Compilation error: Compiler Build time: 00:00:40

Full integration - Windows Build 3890 outcome was FAILURE using a merge of cad95609308a201aea8a24a517992aa5b63e576f
Summary: Compilation error: Compiler Build time: 00:03:00

Merging to ladybird


Added Education and Career page

This pull request introduces two new pages to the website: Education and Career.
Changes Made:

Created a dedicated Education page that highlights various educational resources, coding, and technology subjects.
Developed a Career page outlining potential career paths, opportunities, and resources for professional development.
Implemented responsive design and smooth navigation between the new pages and the existing content.
Enhanced user experience with a cohesive layout and informative content on both pages.

Testing:

Verified that all links and functionalities work as expected.
Ensured that the pages are responsive and display correctly on various devices.

Video
https://github.com/user-attachments/assets/03dc1692-be35-4ce3-b933-eb3f4b4c36f4
Issue number - Fixes #183
@Vin205 Please review this PR and change the label to level2 as its more of a task to create a new page and add it..

Hello PA please review this


Decompression payload if needed in KeyShared subscription

Fixes #7414
Motivation
Decompression payload if needed in KeyShared subscription
Verifying this change
Unit test added
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (no)
The public API: (no)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (no)
The rest endpoints: (no)
The admin cli options: (no)
Anything that affects deployment: (no)

Documentation

Does this pull request introduce a new feature? (no)

@codelipenghui Oh, great. it is pretty fast.
Was it related to the changes in between 2.5.0 and 2.6.0 ?
Just asking because it doesn’t look so.

@feeblefakie it's introduced by #7107.

@codelipenghui Thank you ! 🙇♂

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks


Can we change the min iOS version to 10 or less ?

Right now I am not able to use this pod because its min supported platform version for iOS is 12, which is quite high. Is there a  reason for this.
I am getting the following
    Flipper-Folly (from `/Users/prit91/fbsource/xplat/sonar/iOS/Podspecs/Flipper-Folly.podspec`) was resolved to 2.6.0, which depends on
      boost-iosx (~> 1.76.0)

Specs satisfying the `boost-iosx (~> 1.76.0)` dependency were found, but they required a higher minimum deployment target.

Let's try! I changed ios.deployment_target to '10' in branch 1.76.0
Could you test it?  pod 'boost-iosx', :git => 'https://github.com/apotocki/boost-iosx', :branch => '1.76.0' If it works I'll push the changes into cocoapods repo.


Autosubmit bot should include PR body in commit message

Right now it just uses the title, and we lose sometimes important context.

/cc @ricardoamador

@keyonghan There is currently an open pull request for this: https://github.com/flutter/cocoon/pull/2612


angry mech for wolf

Hello,
Angry mech seems not working with that code:
BadWolf:
    type: entity
    entity_type: e@wolf[angry=true]
    custom_name: <red>Bad Wolf
    age: adult

or
BadWolf:
    type: entity
    entity_type: e@wolf
    custom_name: <red>Bad Wolf
    angry: true
    age: adult

Thanks

Wolves need a target to attack to be angry. Unfortunately setting a wolf's target to itself makes it suicide. You can around this using the attack command, and canceling the damage it does to itself
...
- attack <wolf entity> target:<same wolf entity>
...
on wolf damages wolf:
- if <context.entity.is[==].to[<context.damager>]> determine cancelled


Remove tailwinds anti-pattern in ListRepositories.tsx

Context is on the tracking issue - https://github.com/open-sauced/hot/issues/267
This issue only needs changes to this file.

.take


error when run command ":CocCommand pylsp.builtin.install"

[coc.nvim] Error on notification "runCommand": Client is not running and can't be stopped. It's current
state is: 2

What operating system are you using? Also, do you have python3 installed in your environment?
I don't know what the cause is because I cannot reproduce it in my environment.


Project's firebase

Hi, excellent project. is there any way for you to share the project's firebase? Or the structure? I would like to recreate it.

@telmas you need to create any structure. Just give necessary permissions in the firebase and connect your project to the firebase.

Here are some steps to quickly connect firebase with the project

Firebase-> authentication ->signin method -> enable login with email/password

Firebase -> database -> real-time database -> rules
Remove old rules and paste the following lines

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

Firebase -> storage -> rules -> edit rules
Remove old lines and add below lines

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if true;
    }
  }
}

Download firebase plugin in android studio

In android studio goto tools -> firebase

Connect firebase with an existing or new project
Add Storage dependency
Add database dependency

Thank you very much! Was able to get it working.


Formatter: Expands function call after multi-line string

"""
{}
""".format("hi")

should be formatted as
"""
{}
""".format(
    "hi"
)

This depends on the string content, e.g.
"""{}""".format("hi")

does not get expanded.

It looks like this no longer happens in Black's preview style: https://black.vercel.app/?version=main&state=_Td6WFoAAATm1rRGAgAhARYAAAB0L-Wj4ACHAFhdAD2IimZxl1N_Wk8Jgdzhwf57J25o-MMyJFDdKTbHVMsgIS4qWrqO3MV-q3-8HoAKJvbhIFbv_2jUfXQyafZeaz7n_OCmk3vdd7F3rCF3dZvDEseZ-a6DkyQAYnRsQVfRpAwAAXSIAQAAADwHzGqxxGf7AgAAAAAEWVo=

Okay, I think it's https://github.com/psf/black/issues/256 and https://github.com/psf/black/pull/1879. Closing as I think this is reasonable given it's in preview.

However, there's another behavior implemented in the linked PRs that we don't have: https://github.com/astral-sh/ruff/issues/6581.


flow citation-data into redesign-citation page

example url: https://dlibwwwcit.services.brown.edu/disa_demo/redesign_citations/750/

Hi, commenting on your issue!

For citation #750

Am populating archive, author, date, place, title, and url.
Not yet populating volume, publisher -- or acknowledgements, comments.

Should likely add if-statements to value displays, so that if there is no value, the placeholder will show.
Putting this work on hold to make denormalized data ignore items marked-for-deletion.

I'll get back to this after the community-meeting.


Introduce skipInheritingClasses parameter

Fixes gh-635.

Probably solves the same problem as https://github.com/kongchen/swagger-maven-plugin/pull/531

PR has been updated. Thanks @who !


Convert JSON to MultiJson in Docker::Util

This was missed during the MultiJson conversion

/cc @apophis90

Awesome, thx :)


Apply runc patch to fix nnp issues

Fixes: https://github.com/ubuntu/microk8s/issues/784

@joedborg @jdstrand while investigating the issues @giner reported on this patch I did a rebase to see how this PR goes with v1.19. Unfortunately, calico will not play well. Although the calico-node comes up, the calico-controller (and any other pod I tried) is crashlooping. This may be related to the strict confinement work. The latest/edge/runc-nnp branch is updated with the failing snap if you want to have a look.

Not applying this is problematic and I strongly suggest that the issues with calico be looked at more closely before NAKing this. containerd is not working correctly today and this patch makes it work right for many cases. Without applying this patch, https://github.com/ubuntu/microk8s/issues/784 remains. Furthermore, as mentioned in https://github.com/ubuntu/microk8s/issues/784#issuecomment-675714924, this patch is needed for strict and classic because without it, containerd isn't always going to operate as intended and it won't be able to apply security restrictions in the manner it is being told to do so.
I unfortunately don't have the time to look at this now, but have confirmed with @joedborg that calico is not working correctly in strict and devmode. I think someone needs to look at strace/etc to determine where things are failing if this is failing with classic.


Fix: only 1 message is loaded when few messages (<5) are present in narrow.

Nope, that is not the solution :)
We are intentionally not loading more messages, or it will mess up the positioning within the list.

hmm, 471fa68 will result in messing up scroll position (as it was before).
Best way to scroll to first unread message will be to do it via AnchorScrollView. (which I am planning to do next.) :)
But the problem is: if we send numAfter: 0 then only 1 message is fetched (as useFirstUnread: true) and whole screen is empty. Thus scrolling is not enabled on Android, and we can't fetch more new (unread) messages as no scroll event. Resulting in showing unread count at top and no changes on scroll. :)
On iOS we can get more messages via scroll.
And with fetchMessages(narrow, 0, config.messagesPerRequest, 0, true);, it was near first unread message only on iOS, as in iOS list is scrolled to end. But in Android, most of the time (almost always) list is scrolled to top, so one needs to scroll over read messages in order to get first unread message. :)
b6dcea5 and 801b947 fixes caught up issues.
Before b6dcea5: if newer caught up is true and if we fetch older messages then after fetching it was making newer caught as also false (depending on condition according to newest data). Ideally one direction fetching should have no effect on other direction caught up. (Am I going wrong here?)
Before 801b947: narrowed messages fetch was not resulting in storing/re-calculating caught up. So after fetching, caught up data is null. Thus when new message is arrived, it doesn't find caught up as true and not adding message at the bottom of the list. :)

Rebased 👍

@vishwesh3 after several PRs of mine and yours, do you think this one is still relevant?

yup! we can close this. Definitely not in right direction. But learned a lot working on it :)


update CONTRIBUTING to clarify running locally with ngrok

While trying to contribute to the project, I had difficulty with the initial setup because how limited the free version of ngrok is. These changes will hopefully enable new contributors to jump into development more easily

I'm going to close this PR as we've redone the contributing docs as part of a piece of work to make it much simpler for people to develop and contribute with the app.


[2.0.0 NuGet released version] PostgresException: 42883: operator does not exist: character = integer

This simple query throw aforementioned exception after upgrade to version 2.0.0
context.MyTable.Where(w => w.myfield == "011")
myfield is defined as character(3) on PostgreSQL 9.6.4.
The problem could be related to the impossibility of execute a "fresh" scaffold-dbcontext, as reported in this issue #228  , because in my actual dbcontext I've following fluent API code:
entity.Property(e => e.myfield)
                    .HasColumnName("myfield")
                    .HasColumnType("bpchar")
                    .HasMaxLength(3);

If I change bpchar to varchar my query succeeded.

The problem is in NpgsqlDatabaseModelFactory class, GetColumns method.
I've this old table
CREATE TABLE public.mytable
(
  comdes character(35) NOT NULL,
  comist integer,
  comcod character(4),
  CONSTRAINT mytable_pkey PRIMARY KEY (comdes)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.mytable
  OWNER TO postgres;

where "comdes" field is defined as CHARACTER(35) and pg96 internal is

Actually there are these statements in GetColumns method
// bpchar is just an internal name for char
                    if (dataType == "bpchar")
                        dataType = "char";

that generate my model like this (ver. 2.0.0)
public partial class mytable
    {
        public char Comdes { get; set; }
        public int? Comist { get; set; }
        public string Comcod { get; set; }
    }

instead of this (ver. 1.1.1)
public partial class mytable
    {
        public string Comdes { get; set; }
        public int? Comist { get; set; }
        public string Comcod { get; set; }
    }

This is wrong because if "bpchar" length is greater than 1 should be "varchar", and consequently "string" in my model instead of "char".

Will try to take a look at this ASAP

Closed via #370


ValueError: invalid literal for int() with base 10

Discribe the bug

Traceback (most recent call last):
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/gpfs/home/jj323/infinigen/infinigen/datagen/manage_jobs.py", line 812, in <module>
    main(args)
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/site-packages/gin/config.py", line 1605, in gin_wrapper
    utils.augment_exception_message_and_reraise(e, err_str)
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/site-packages/gin/utils.py", line 41, in augment_exception_message_and_reraise
    raise proxy.with_traceback(exception.__traceback__) from None
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/site-packages/gin/config.py", line 1582, in gin_wrapper
    return fn(*new_args, **new_kwargs)
  File "/gpfs/home/jj323/infinigen/infinigen/datagen/manage_jobs.py", line 675, in main
    manage_datagen_jobs(all_scenes, elapsed=(now-start_time).total_seconds())
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/site-packages/gin/config.py", line 1605, in gin_wrapper
    utils.augment_exception_message_and_reraise(e, err_str)
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/site-packages/gin/utils.py", line 41, in augment_exception_message_and_reraise
    raise proxy.with_traceback(exception.__traceback__) from None
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/site-packages/gin/config.py", line 1582, in gin_wrapper
    return fn(*new_args, **new_kwargs)
  File "/gpfs/home/jj323/infinigen/infinigen/datagen/manage_jobs.py", line 603, in manage_datagen_jobs
    LocalScheduleHandler.instance().poll()
  File "/gpfs/home/jj323/infinigen/infinigen/datagen/util/submitit_emulator.py", line 181, in poll
    total = self.total_resources()
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/site-packages/gin/config.py", line 1605, in gin_wrapper
    utils.augment_exception_message_and_reraise(e, err_str)
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/site-packages/gin/utils.py", line 41, in augment_exception_message_and_reraise
    raise proxy.with_traceback(exception.__traceback__) from None
  File "/gpfs/home/jj323/mambaforge-pypy3/envs/infini/lib/python3.10/site-packages/gin/config.py", line 1582, in gin_wrapper
    return fn(*new_args, **new_kwargs)
  File "/gpfs/home/jj323/infinigen/infinigen/datagen/util/submitit_emulator.py", line 158, in total_resources
    visible = [int(s.strip()) for s in os.environ[CUDA_VARNAME].split(',')]
  File "/gpfs/home/jj323/infinigen/infinigen/datagen/util/submitit_emulator.py", line 158, in <listcomp>
    visible = [int(s.strip()) for s in os.environ[CUDA_VARNAME].split(',')]
ValueError: invalid literal for int() with base 10: 'GPU-c5aa4d0e-51b8-94f4-8799-3f17f14b64ea'
  In call to configurable 'total_resources' (<function LocalScheduleHandler.total_resources at 0x14f7115e6c20>)
  In call to configurable 'manage_datagen_jobs' (<function manage_datagen_jobs at 0x14f7113f7370>)
  In call to configurable 'main' (<function main at 0x14f7113f7250>)

Steps to Reproduce
python -m infinigen.datagen.manage_jobs --output_folder outputs/my_videos --num_scenes 50 --pipeline_config local_128GB.gin monocular_video cuda_terrain opengl_gt --cleanup big_files --warmup_sec 60000 --config video high_quality_terrain

I tried to comment the code in infinigen/infinigen/datagen/util/submitit_emulator.py from line 163~166 (link) and it fixed.
I wonder if this is a correct solution.

It seems your CUDA_VISIBLE_DEVICES contains long strings like GPU-c5aa4d0e-51b8-94f4-8799-3f17f14b64ea where I (incorrectly) had assumed it was only integers. Could you try removing the int(..) from int(s.strip()) so it just looks like [s.strip() for s in os.environ[CUDA_VARNAME].split(',')]? If this works for you I will patch it into main. I should probably find and follow some kind of specification for what these are allowed to look like.

Yes. This works.


Tests are mistakingly included into the wheel

Describe the bug
find_packages has been used recklessly, tests dir hasn't been excluded.

[x] I have checked that this issue has not already been reported.
[x] I have confirmed this bug exists on the latest version of pandera.
[x] (optional) I have confirmed this bug exists on the master branch of pandera.

Expected behavior
Must be excluded.

fixed by #739


VMWare Discovery

Proposal
Use case. Why is this important?
We would like to monitor all ESXI hosts and also all virtual machines in a VMWare vCenter environment; however since VMs and ESXI hosts are so dynamic (they come and go super often) it seems silly to define them statically.
We could use dns_sd_configs however that doesn't seem right as there would be no distinction between ESXI hosts for example and VMs.
If prometheus had VMWare discovery built in that scraped a vCenter for targets then that woiuld be awesome

There are a vmware file_sd config generator that could be used as a basis for implementing this.
https://github.com/AppliedTrust/vmware-filesd

https://github.com/vmware/govmomi/blob/master/examples/virtualmachines/main.go is be the Go equivalent of this, and adding in<EMAIL_ADDRESS>would allow you to get the tags.

There are a vmware file_sd config generator that could be used as a basis for implementing this.
https://github.com/AppliedTrust/vmware-filesd

That one is gone now, any idea where it can easily be found again?
(Implementing custom SD stuff as "web" servers that can be scraped by http_sd might make sense)


Some problem in Thumbnail function.

There is a premise that we must ensure the integrity of image, so I think there is some problem in Thumbnail function that the if condition is reverse.
	if srcAspectRatio > thumbAspectRatio {
		tmp = Resize(img, 0, thumbH, filter)
	} else {
		tmp = Resize(img, thumbW, 0, filter)
	}

Hello,
Can you please provide an image and a code example demonstrating the issue? I can't see what's the problem with this code.

I mean the condition need reverse.
if srcAspectRatio < thumbAspectRatio {

No, the Thumbnail works as intended. It resizes and crops an image to fill the rectangular area.
Probably you should use another function - Fit. It resizes an image to fit the given dimensions.

I'm sorry, you are right, Fit fits me.


error when running on the customized dataset

I run the program on my dataset, got the error like as follows, according to the error, there is something wrong with the unzip function, so I print out all the random samples and unzip result, however, I cannot find any error, wonder if you have any hints on it? Thanks
random samples: [((5, 8), 1), ((3, 9), 4), ((8, 9), 1), ((4, 5), 1), ((1, 9), 6), ((2, 5), 3), ((2, 4), 2), ((4, 9), 3), ((2, 8), 4), ((3, 4), 1), ((2, 9), 5), ((2, 3), 1), ((1, 8), 5), ((5, 9), 2), ((3, 5), 2), ((1, 3), 2), ((1, 5), 4), ((3, 8), 3), ((1, 2), 1), ((1, 4), 3)]
unzip result ((5, 8), (3, 9), (8, 9), (4, 5), (1, 9), (2, 5), (2, 4), (4, 9), (2, 8), (3, 4), (2, 9), (2, 3), (1, 8), (5, 9), (3, 5), (1, 3), (1, 5), (3, 8), (1, 2), (1, 4)) (1, 4, 1, 1, 6, 3, 2, 3, 4, 1, 5, 1, 5, 2, 2, 2, 4, 3, 1, 3)
Train epoch 0:   0%|▎                                                                                | 13/3980 [00:04<22:55,  2.88it/s]/lrlhps/apps/python/python-3.6.5/lib/python3.6/multiprocessing/semaphore_tracker.py:143: UserWarning: semaphore_tracker: There appear to be 1 leaked semaphores to clean up at shutdown
len(cache))
/lrlhps/apps/python/python-3.6.5/lib/python3.6/multiprocessing/semaphore_tracker.py:143: UserWarning: semaphore_tracker: There appear to be 1 leaked semaphores to clean up at shutdown
len(cache))
/lrlhps/apps/python/python-3.6.5/lib/python3.6/multiprocessing/semaphore_tracker.py:143: UserWarning: semaphore_tracker: There appear to be 1 leaked semaphores to clean up at shutdown
len(cache))
/lrlhps/apps/python/python-3.6.5/lib/python3.6/multiprocessing/semaphore_tracker.py:143: UserWarning: semaphore_tracker: There appear to be 1 leaked semaphores to clean up at shutdown
len(cache))
Process SpawnProcess-1:
/lrlhps/apps/python/python-3.6.5/lib/python3.6/multiprocessing/semaphore_tracker.py:143: UserWarning: semaphore_tracker: There appear to be 1 leaked semaphores to clean up at shutdown
len(cache))
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "/lrlhps/apps/python/python-3.6.5/lib/python3.6/multiprocessing/pool.py", line 119, in worker
result = (True, func(*args, **kwds))
File "/lrlhps/users/c272987/spert/spert/sampling.py", line 237, in _produce_train_batch
sample = _create_train_sample(d, neg_entity_count, neg_rel_count, max_span_size, context_size)
File "/lrlhps/users/c272987/spert/spert/sampling.py", line 296, in _create_train_sample
neg_entity_spans, neg_entity_sizes = zip(*random_samples)
ValueError: not enough values to unpack (expected 2, got 0)
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/lrlhps/apps/python/python-3.6.5/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap
self.run()
File "/lrlhps/apps/python/python-3.6.5/lib/python3.6/multiprocessing/process.py", line 93, in run
self._target(*self._args, **self._kwargs)
File "/lrlhps/users/c272987/spert/spert.py", line 12, in __train
types_path=run_args.types_path, input_reader_cls=input_reader.JsonInputReader)
File "/lrlhps/users/c272987/spert/spert/spert_trainer.py", line 111, in train
input_reader.context_size, input_reader.relation_type_count)
File "/lrlhps/users/c272987/spert/spert/spert_trainer.py", line 182, in _train_epoch
for batch in tqdm(sampler, total=total, desc='Train epoch %s' % epoch):
File "/lrlhps/users/c272987/spert/env/lib/python3.6/site-packages/tqdm/_tqdm.py", line 955, in iter
for obj in iterable:
File "/lrlhps/users/c272987/spert/spert/sampling.py", line 155, in next
batch, _ = self._results.next()
File "/lrlhps/apps/python/python-3.6.5/lib/python3.6/multiprocessing/pool.py", line 735, in next
raise value
ValueError: not enough values to unpack (expected 2, got 0)

you are right, I also found that issue, can I simply put extra if statement to evaluate if the random sample result is empty, if it is empty,  then don't do the unzip ?


Link to first page of article

The edit is to point the link to the root of the article, instead of the second page. I thought the article was really hard to follow, and poorly written. Turns out I was on the second page, which wasn't clear until getting to the end of the article.

Umm, not sure this is right... the first page is most of what deals with the Unity test framework - which is the one in use. Page two only deals with it's output (admittedly the main concern for anyone just doing the exercises) and CppUTest, the latter of which makes up the majority of the page and likely to be even more confusing as it is not the framework being used.

Figured that it was done on purpose, that's why I shared my experience as a reader. Feel free to close without merging. :)

Whoops, I misunderstood your meaning (blame it on a late Sunday evening!) You meant that the original links to the second page where should link to the first page. You are correct there then 😄


removed javascript:void(0)

because it's an "unsafe" practise and gives an error in console.

cool!

cool!


Is this line correct?

https://github.com/andrewliao11/gail-tf/blob/adfffb64da2020146c0d4c6de661b775c47a9993/gailtf/network/adversary.py#L57
Should the line above be:
obs = (obs_ph - self.obs_rms.mean) / self.obs_rms.std
instead of
obs = (obs_ph - self.obs_rms.mean / self.obs_rms.std)
If I am confusing something, please let me know.

good catch, can you send me the pull request for this
?

Done. I have another question. How are the mean and std of self.obs_rms being updated? I don't see them being updated anywhere. Maybe I am missing something?

Done. I have another question. How are the mean and std of self.obs_rms being updated? I don't see them being updated anywhere. Maybe I am missing something?

Hi @rubenvillegas ,
I update the running mean in the main training loop (here)

Got it! Thank you. One last question. How important did you find normalizing the input?

it's the convention to normalize the input.
However, if the absolute values are required (e.g., the coordinate of the obstacles or targets), i won't normalize it.

Ok cool. Thanks!!


Logged in users must be able to create a list

As a logged in user,
I must be able to create a list,
In order to store lists.

As an anonymous user,
I cannot create a list.

As a logged in user,
When I create a list,
I must be able to specify a title for that list.

As a logged in user,
When I create a list,
I must be able to specify a color for that list.

As a logged in user,
When I create a list,
I must be able to create a list of states for that list,
Where the default states are ['not done', 'done'],
so that I can set those states on individual items.

As a logged in user,
When I create a list,
I must be able to specify a cover image for that list,
which I can upload,
in order to set the cover image for the collapsed tile.

what kind of list are we talking about?

NOTE: The default dashboard view will be a tiled view of the most recently used and popular lists. Each tile will be similar to the tiles at https://vuetifyjs.com/en/components/cards/#grids. So the cover image is the image which is shown on the tile, not really an "avatar," as was mentioned in our call. However, it doesn't really matter for now - we can work on how we are going to use this data later.

I am sorry to close and reopen this ticket
Could you please clarify the following?
"As a logged-in user,
When I create a list,
I must be able to specify a cover image for that list,
which I can upload,
in order to set the cover image for the collapsed tile."

In the dashboard view, the lists will be nothing more than tiles. The background of the tiles should have a photo, much like an album cover for a CD or record.

For more on the Tiles, see #22


Add couchdb.cr to the list

@Schniz @TechMagister looks like it is not maintained. This shard doesn't compile

Well, it was just reviewed and merged 😸
Everything compiles on my machine, and tests pass.

Yes, it now works for me. However, to be able to merge I would like to see at least one published release and CI builds. See official guidelines on how to create/maintain a shard: https://crystal-lang.org/docs/guides/writing_shards.html
Also, we are thinking about required weekly CI builds (#347) for new entries. For a moment, it is not a blocker for you, but if you want, you can experiment.
Making the list awesome and up to date is not that easy. We want to add the best shards and be sure they are propertly maintained. Thanks for understanding.

Hi, the first version was just released: https://github.com/TechMagister/couchdb.cr/releases/tag/v0.1

Also, we are thinking about required weekly CI builds...

Sounds awesome and very reasonable. I'll try making a CI config for this project too - so it won't break over time.

Making the list awesome and up to date is not that easy

I'm sure - and I'm thankful that you're doing that. Thanks ✨

Hi! Now it contains a CI badge


gateways.networking.istio.io and gateways.networking.x-k8s.io conflicts

Both crds have accepted name gateway. I tried to get istio gateway by kubectl get gateway we could get nothing.  I think the service apis' gateways.networking.x-k8s.io takes precedence in my cluster.
It is confusing for newbie.
@howardjohn

Yes, they may change the name. You can do get gw by the way.
I opened an issue in k8s to print a warning when there is a conflict

https://github.com/kubernetes/kubernetes/issues/94860


Onboard Manual Mode

Summary
What is the feature all about? Is it a game, a utility, an enhancement, or something else?
Onboard Manual Mode is pretty much the online/paper swadge manual, but on the swadge itself.
Users should be able to:

Read the manual
Jump between chapters with a side menu
Perform a text search
Follow hyperlinks leading to anchors elsewhere in the manual

Technical Spec
How will this be implemented?
What peripherals will be used, and how?
Much of the work would be porting / rewriting the existing prototype implementation that was created for the 2023 swadge. This contains just the main functionality of parsing and rendering markdown-ish files.
Perhaps the touchpad can be used for smooth scrolling too.
The prototype contains a full markdown parser that supports basic standard markdown (headers, horizontal rules, bold/italic/underline/strikethrough, single-vs-double-newline break behavior), and also escape sequences for things which aren't possible in pure markdown, like color changes (\c000), alignment changes (\lCCentered Text\L). It also supports parsing standard markdown image tags (and alt text), but not loading or rendering images. We could modify the existing parser to better fit the needs of the final version of the manual. If you want to see what the markdown-ish format actually looks like, compare this file to the screenshot below.
Technical info about the existing markdown parser
The parser itself builds a tree (apparently it's called a "left-child right-sibling tree") structure from the text. Each node in the tree has a child, sibling, and parent (just for faster traversal in reverse) pointer, a unique index, and then the node data itself. The node data depends on the type, but it's generally just an enum value, and maybe pointers to within the main text. The main text never gets copied since we can fake having substrings by having an end-pointer for all strings within the text. Overall, each node is around 32 bytes and represents either a continuous text span of any length, a "decoration" (non-text node), or the start of a new text style.
The text only needs to be parsed once to generate a markdown tree, which can then be rendered within bounds and continued just like the normal word-wrap text functions do. The markdown renderer just uses an opaque pointer as a "continue" point, which internally just has a pointer to the both the text and the markdown node. The existing mode has some code that pre-paginates the pages and caches the result, but that's likely (though untested) to be unnecessary now that the billion printfs have been removed from the rendering process and it's actually fast on the real swadge.
In whatever state it ends up in, any markdown/rich text support that's used for the manual can be made into a library that could be used by other swadge modes too.
UI
What are the display screens & menus (if applicable)?
What user inputs are there for each screen?
Not sure if there would be an overall main menu or not. If so, it would just be a bigger version of the main menu.
Aside from the main reading area, there would be some sort of collapsible side pane, or maybe an entire screen, that would let the user scroll between chapters/subchapters quickly.
There would also be a search feature, on a pane/screen similar to the chapter select pane. First it would show the text entry dialog, then once text was entered it would go to a page which lists the results, which the user could scroll through to select and navigate to the text in its place, or the user could go back to the text entry screen to modify the search.
Mockups
Paste any mockups of screens or anything else here.

How to Test
How can we verify the feature is working?
Read manual, make sure doesn't look wrong?

Some more thoughts:
In the previous manual implementation, most of the existing library code that was updated was for the purpose of adding bold/italic support to the text functions. Those could instead be added, if at all, by just using a different font without having to change anything, I think.

Yep, different fonts would work for bold or italic text.
Text search and hyperlinks sound nice, but feel like way overkill. If the modes are so complicated that text search is required, we already did something wrong. Also text input with a d-pad is pretty meh. Hyperlinks are more feasible, but I still don't see them getting used.
I'm also gonna bet now that when the post-mag survey comes, back, the usage stats for the manual are gonna be slim.


Light Theme style error

Light Theme:

Dark Theme:

light Theme var undefined:

This was fixed recently, thanks for reporting!


Run make generate to make files consistent

Changes
Not sure where the mistake happened, but somehow the prune flag seems to have disappeared from the BuildRun OpenAPI.
Submitter Checklist

[ ] Includes tests if functionality changed/was added
[ ] Includes docs if changes are user-facing
[x] Set a kind label on this PR
[x] Release notes block has been filled in, or marked NONE

Release Notes
NONE

/approve


Tracking: Upgrade to<EMAIL_ADDRESS>

It would be nice to be able to upgrade to<EMAIL_ADDRESS>I'm opening this to track the issue, and potentially investigate fixes.
There is an issue filed in the react-native project at: https://github.com/facebook/react-native/issues/2010
In the meantime, we may be able to implement a retry workaround. @lightsofapollo commented there with,

Okay after a minimum of digging it turns out that it's a fairly simple race... It looks like pre 0.7 attempting to access viewRegistry for a particular reactTag was more deterministic (or the race was smaller) ... In my case I wrap my access to viewRegistry in a retry (which itself is only called in addUIBlock blocks).

Thanks @KevinGrandon. At the moment I think the current version can be compiled against 0.8 version of react-native. However, because of that issue, you will be stuck!
I can't wait to opgrade, but because my app is depends on WebView heavily, I can not risk it. I just have to wait a little bit longer. I might end up fixing the react-native bug if I find some time off in the weekend!

@alinz - When trying to upgrade to 0.8 locally, I ran into this error message: 'Error: undefined is not a function (evaluating \'this.getWebWiewHandle()\')\n stack: \n  getWebViewBridgeHandler
This seems a bit different than the one reported in the react-native bug. Were you seeing this error message as well?

@KevinGrandon My current app is heavily dependent on WebView. I have been blocked by that issue 2010. I really want to continue but until this bug gets fix, there is no point to upgrade to 0.8.
However, I will give it another shot by end of today or tomorrow. I will let you know.
btw, thank you for helping me out.

There is a typo in the jsx script file -- it says "getWebWiewHandle" instead of "getWebViewHandle". Didn't solve my problem, but nonetheless...

@skitterm this is really funny! until 0.8-rc2, it was getWebWiewHandle and they have change it to getWebViewHandle at this commit. Thanks for pointing this out.
As far as I know, the WebView bug still there. I'm trying to find some time and find the actual bug in react-native. Still not find the time. I will let you know soon!

Sounds good. A little more digging on my part: I found that on ComponentDidMount, WebViewManager didn't have the bridgeSetup method attached (the only methods that were there were goBack, goForward, and reload, and the NavigationType property).

OK, I have released a new version which fixes the crash issue in react-native 0.7 above. Please upgrade to 0.3.2 and let me know if you have this issue.
cc: @skitterm @KevinGrandon

I'm going to close this issue since I have tested with 0.8 and above. One thing you guys have to be aware is that, 0.9 has -rc in there version number which causes npm to throw an error. For time being, you can fork the react-antive and edit the package.json or fork this project and added -rc to dependencies value.

It looks like I still have the same error: undefined is not a function (evaluating WebViewHandler.bridgeSetup(handlerId)) at WebViewBridge, line 76.
I'm using React-Native 0.8.0 and version 0.3.2 of this library (and the newest version of the react-native-cli). I created a new project with the CLI, linked up the library, added in a basic WebViewBridge, and ran it. The above error was what I got. I had the same issue with the example in the node_modules folder.

@skitterm this only happens if you don't include the objective-c into your project.
I have tested the Sample project and it seems working. So I think you missed one step.
Here's my approach to install this library.
1: add the react-native-webview-bridge in your project's package.json.
2: npm install
3: go to xcode and right click on Libraries
4: select Add files to "..."
5: go to node_modules/react-native-webview-bridge and select WebViewBridge
make sure that you see your Libraries folder like this:

compile and run the app.

One more thing, I have updated the version to 0.3.3, I found the bug and I fixed it.

It seems that the "undefined is not a function (evaluating WebViewManager.bridgeSetup(this.getWebViewBridgeHandler());" is coming back. I am using 0.3.5 and React Native 0.9.

I've been using this in my app with react-native 0.10 and I have not seen this issue. Can you provide me some sample code? then I can help you with this.

Hi alinz, here is my index.io.js:
/**
 * Sample React Native App
 * https://github.com/facebook/react-native
 */
'use strict';

var React = require('react-native');
var WebViewBridgeNative = require('react-native-webview-bridge');

var myPageScripts = function() {
  function WebViewBridgeReady(cb) {
    if (window.WebViewBridge) {
      cb(window.WebViewBridge);
      return;
    }
    function handler() {
      document.removeEventListener('WebViewBridge', handler, false);
      cb(window.WebViewBridge);
    }
    document.addEventListener('WebViewBridge', handler, false);
  }
  WebViewBridgeReady(function (WebViewBridge) {
    WebViewBridge.send("Hello this is me calling from web page");
  });
};

//convert function definition into string
myPageScripts = `(${myPageScripts.toString()}());`;

var {
  AppRegistry,
  Component,
  StyleSheet,
  Text,
  View,
} = React;

class WVTest extends Component {
  constructor(props) {
    super(props);
    this.once = true;
  }

  componentDidMount() {
    var myWebViewBridgeRef = this.refs.myWebViewBridge;

    var onMessage = function(message) {
      console.log("Received message", message);
    };
    myWebViewBridgeRef.onMessage(onMessage);

    myWebViewBridgeRef.injectBridgeScript();

    //this opens up the printer window dialoge
    setTimeout(() => {
      myWebViewBridgeRef.print();
    }, 5000);
  }

  onNavigationStateChange(navState) {
    var myWebViewBridgeRef = this.refs.myWebViewBridge;
    if (this.once) {
      this.once = false;
      setTimeout(() => {
        myWebViewBridgeRef.evalScript(myPageScripts);
      }, 1000);
    }

    console.log(navState.url);
  }

  render() {
    var url = 'http://google.com';

    return (
      <WebViewBridgeNative
        ref="myWebViewBridge"
        onNavigationStateChange={this.onNavigationStateChange.bind(this)}
        url='web/index.html'
        style={{flex: 1}}/>
    );
  }
}

var styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#F5FCFF',
  },
  welcome: {
    fontSize: 20,
    textAlign: 'center',
    margin: 10,
  },
  instructions: {
    textAlign: 'center',
    color: '#333333',
    marginBottom: 5,
  },
});

AppRegistry.registerComponent('WVTest', () => WVTest);

I have try leaving url: {url} in the render() function but it's the same. Here is the index.html under web/ :
<!DOCTYPE html>

    <meta charset="UTF-8" />

Hi

    <canvas style="width:100%"></canvas>

After I click on Dismiss (ESC) the page does show up (displaying "Hi"). Below is the screen shot of my project. Thanks for looking into it.

You might need to add the files individually to the Libraries folder (instead of adding the entire folder).

Have just tried that. Now got these compile error. Not sure why Xcode doesn't recognize nonnull?

Remove the nonnull if you are using react-native under 0.9.

Wow, that does the trick! The error is gone and it works now. Thanks for the help!

nonnull was introduced to the react-native api to compatible with Android version. Always read the release notes from the api to make sure you don't break any changes. here's the link

I think I am using react-native 0.9.0. Should I add the nonnull only after upgrade to 0.10.0?

@seanchenca Yes! based on release note, you should use nonnull after upgrading to 0.10.x

Thanks for the info alinz. Will remember to add them back once I upgrade.

Had the same issues even thought I followed the instructions in  [Linking Libraries(]http://facebook.github.io/react-native/docs/linking-libraries-ios.html) as it was my first react-native project and didn't have a clue where to begin.
I realised that the this library didn't build properly so I commented out the code that didn't work. In this case RCTLogMustFix().
(Running in react-native 0.15.0 within Xcode 7.1).

@johanmontan I have updated the doc and released a new version. Please give it a shot and let me know.


[LCS] Use serde_stacker to avoid stack blowups

DO NOT MERGE; This is a PoC pending resolution of an upstream PR.
This uses a stack-growth library (stacker) behind a serde adapter to help with stack size in (de)serialization.
The perf cost seems manageable (< 10%):
https://gist.github.com/huitseeker/6cd90ee29d90b7ce0c0cb00f5a263fe1#file-gistfile1-txt-L1-L4
Fixes #3046.
The present PR is offered as a PoC, and uses my personal repo to enact a small fix on serde-stacker. It will be modified to point to the normal crate once a new release of serde-stacker comes out.
This is still WIP, but tests will pass once with https://github.com/dtolnay/serde-stacker/pull/8 merged upstream (they rely on branching on is_human_readable in the (de)serialization of AccountAddress).

cc @vgao1996 and @bmwill who have had to look at similar issues

on serde stacker:

Be aware that you may need to protect against other recursive operations outside of serialization and deserialization when working with deeply nested data, including, but not limited to, Display and Debug and Drop impls.

:umbrella: The latest upstream changes (presumably b3210fd4545ea1c26539ec9821c57d78a5c23073) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably 010691260f4c91b21dd669ddb9715d0ffdf27dd0) made this pull request unmergeable. Please resolve the merge conflicts.

Sorry for the late reply. Finally had some time to think about this. Based on my own experience writing #3572 and #3596, and a failed attempt to make Drop::drop non-recursive for SignatureToken, I'd say that

Serialization/Deserialization is just the tip of the iceberg. The real issue here is that any operation on such recursive structures can blow up the stack.

All such operations need to be written in a careful manner or otherwise the system is still unsafe.
Drop::drop is the real monster, which is tightly coupled with the move semantics and borrow rules of the language, and follow special rules that render a few common fixes impossible.

serde_stacker does offer an interesting solution that can be adapted to rewrite all recursive operations: dynamically growing the stack via stacker. This can be another viable option in addition to emulating the stack using a Vec. However I'm not sure if it's dangerous or if we feel comfortable having code that manipulates the stack limit in our TCB. @dariorussi what do you think?
Ultimately I think the most effective way to deal with such data structures is to stop early during or even before deserialization. I think we should terminate once we reach a certain depth, or check before hand if the number of bytes is within limit. (I do realize the former may not be easy if we use serde's implementation.)

the intent of this PR wrapping serde_stacker around LCS is to armor LCS against stack blowups in general, including serialization, and without limitation to Drop or #3046,
on comprehensiveness, the only really safe implementation of a deeply-nested drop (or deeply-nested serialization) I can think of is manual T.C.O. w/a trampoline, at significant cost in performance,
it's possible to limit the recursion depth in serde, either by contributing a solution to https://github.com/dtolnay/serde-stacker/issues/1 or by implementing it directly in LCS,

All of the things above are three complementary approaches to get a better handle on stack growth in serialization / drop.
With a somewhat higher priority¹, we'll also need to decide if we want to keep serialization as infaillible as it is now (aking to fn to_bytes(&self) -> Vec<u8>) or if we want to explicitly make it faillible (homologous to fn to_bytes(&self) -> Result<Vec<u8>, lcs::Error>).
I think capping recursion depth implies spending time on the later question, which becomes even more important.
¹: we're on the way to bringing serialization on the critical path for signing with https://github.com/libra/libra/pull/4073 and we'll be using it on user-provided inputs when Move contracts can be provided by 3d parties

I chatted with @vgao1996 off thread regarding:

a failed attempt to make Drop::drop non-recursive for SignatureToken

Consider looking at how https://github.com/dtolnay/miniserde implements non-recursive drop on https://docs.rs/miniserde/0.1.12/miniserde/json/enum.Value.html because it would work for SignatureToken.

:umbrella: The latest upstream changes (presumably 957aa12a40297444fc7133c8b5fa56158d8b8cba) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably 7394c2ef97eaad79189557563dee5ea977a282d4) made this pull request unmergeable. Please resolve the merge conflicts.

seems like we won't be going this direction, feel free to re-open if this is a misunderstanding.