[CI/CD] Provisioning tests failures inconsistently affect publish builds

Provisioning tests (provisioning-tests-rke2, provisioning-operations-tests-k3s and provisioning-operations-tests-rke2) are not a hard dependency on manifest step making their impact on manifest step down to timing.
If tests are still running when Drone is ready to start manifest step, it proceeds with it. And then it doesn’t matter whether provisioning tests succeed or fail.
If the provisioning tests fail before Drone is ready to start manifest step, it skips manifest step (same as any other pending steps at the time of failure of provisioning tests).
2 immediately clear ways to fix it:

Make manifest pipeline wait on provisioning tests by adding them to depends_on of that step (code).

The obvious drawback is that it may and will delay getting v2.x-head and RC images published and will outright prevent them from being published if provisioning tests fail.

Add failure: ignore to provisioning tests that run on publish builds.

The obvious drawback is failing provisioning tests may fly under the radar.

At this time option 2 seems to be a more preferable since provisioning tests run on PR (technically there is a chance something will get broken on merge but this chance is minimal and there is not much to gain from not producing build artifacts even if that's the case).
Note: This is marked as kind/flaky-test for visibility purposes, not because it's actually a flaky test.

Closing as linked PR has been merged and publish build ran after it succeeded.


Browser timeout

First of all, ollama is working fine when i use the terminal.
When i use this package, i mostly get connection time out in de browser.

This is not related with the package, probably you need check you max_execution_time in php.ini


support more data types

there's still too many unsupported data types in SwaggerConversion
dates will probably fixed with #40

Could we shortly list those missing?

see commit 2a559f5

[ ] a

@mfirry any tips where to start or what to do in order to add support for more types? I have no idea where to start.

Created a pull request for supporting UUID type: #65


Inconsistent font sizes in configurable header profile dropdown

Description:
The font sizes within the configurable header, specifically in the profile dropdown, are inconsistent across various components.
Actual Result:
The font sizes within the profile dropdown are inconsistent.
Expected Result:
All text elements within the profile dropdown should have consistent font sizes as per the design specifications.

PR

@Tshepiso-R this functionality is handled by the configurable header component, we can close the item.


Collection of temporary API hacks in edge

This issue should contain all the temporary hacks we implemented in the edge branch which should be changed later on.
To not miss anything let's collect them here:

https://github.com/cs3org/reva/blob/edge/internal/http/services/owncloud/ocs/handlers/apps/sharing/shares/spaces.go#L105-L110
https://github.com/cs3org/reva/blob/edge/internal/grpc/services/gateway/storageprovider.go#L300-L303
...

Great idea! There a lot. These are the ones I remember having touched recently...

https://github.com/cs3org/reva/blob/edge/pkg/storage/utils/decomposedfs/spaces.go#L324
https://github.com/cs3org/reva/blob/edge/pkg/storage/utils/decomposedfs/spaces.go#L627
https://github.com/cs3org/reva/blob/edge/pkg/storage/utils/decomposedfs/decomposedfs.go#L178
https://github.com/cs3org/reva/blob/edge/internal/http/services/owncloud/ocdav/spacelookup/spacelookup.go#L46-L53

https://github.com/cs3org/reva/pull/2616

https://github.com/cs3org/reva/pull/2624

https://github.com/cs3org/reva/pull/2666


IOS/Android - Payments - Making payment method default will have keyboard overlapping password prompt

Details

Here we are addressing 2 issues

IOS/Android - Payments - Making payment method default will have keyboard overlapping password prompt

For this issue, we are adding <KeyboardSpacer /> in order to avoid text input to hide behind the keyboard making component usable to the user
With this issue, we are incorporating <KeyboardSpacer /> into our code base and removing the external library which was abandoned

Whitespace on the screen where the keyboard used to be

In order to resolve this issue we are removing <KeyboardSpacer /> from SidebarLinks.js as this causes an issue for white space block UI at keyboard height which I explain here https://github.com/Expensify/App/issues/10188#issuecomment-1206203078

Fixed Issues

$ https://github.com/Expensify/App/issues/9928
$ https://github.com/Expensify/App/issues/10188
Tests (Issue 9928)

Open the app and log in
Tap on the Profile icon > Payments
Tap on a payment method
Tap "Make default payment method"
Verify that keyboard doesn't overlap the password text input

Tests (Issue 10188)

Open any chat
Press on the composer (open keyboard)
Put the app in the background
Open again with the keyboard open
Press back immediately
You should see the bottom space same as the keyboard height

[x] Verify that no errors appear in the JS console

PR Review Checklist

Contributor (PR Author) Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] Any functional components have the displayName property
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] Any functional components have the displayName property
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

QA Steps  (Issue 9928)

Open the app and log in
Tap on the Profile icon > Payments
Tap on a payment method
Tap "Make default payment method"
Verify that keyboard doesn't overlap the password text input

QA Steps  (Issue 10188)

Open any chat
Press on the composer (open keyboard)
Put the app in the background
Open again with the keyboard open
Press back immediately
You should see the bottom space same as the keyboard height

[x] Verify that no errors appear in the JS console

Screenshots (Issue 9928)

Mobile Web

https://user-images.githubusercontent.com/47522946/182147885-1586754f-d72f-4570-b5d2-d32d0d99dba5.mov
https://user-images.githubusercontent.com/47522946/182147899-7321f2f0-95c0-4edf-88bb-4f0214664908.mp4
iOS

https://user-images.githubusercontent.com/47522946/182147815-58eda639-d5e9-40f0-a2c9-2c392818ab56.mp4
Android

https://user-images.githubusercontent.com/47522946/182147773-da7de1c9-f73d-4f4f-a727-86f1081f7213.mp4
Desktop

issue affected only mobile devices which have a keyboard

Web

issue affected only mobile devices which have a keyboard

Screenshots (Issue 10188)
iOS
https://user-images.githubusercontent.com/47522946/183033977-067ac049-caf5-4244-a443-0c08aa5a9731.mp4
This issue only affects iOS so no other platform changes

@dhairyasenjaliya just a gentle reminder to mark this PR as ready for review after you're done with cleaning up the code

Sure, this time I will require a bit of time due to new components changes so will wrap as soon as possible

that's not a problem at all, thanks for letting us know!!

@rushatgabhane do I need to commit package-lock.json since I removed KeyboardSpacer package ?

but it creates different integrity is that fine for merging?

Make sure your npm version is 6.14.17 and then do the npm uninstall etc

hm I have 6.14.9 do I need to downgrade ?

alright we are good to go for review @rushatgabhane

Regarding the freezeing issue you have raised here https://expensify.slack.com/archives/C01GTK53T8Q/p1659503910525829, does this PR also fix that?

We could obviously increase the reward for this and also check if this issue has not been reported before.

Regarding the freezeing issue you have raised here https://expensify.slack.com/archives/C01GTK53T8Q/p1659503910525829, does this PR also fix that?

This PR doesn't solve that one since I believe that issue is related react native reanimation package has some issue with modal so will try to investigate more

related react native reanimation package

I'm pretty sure react-native-reanimated isn't being used in the app. It's just installed.
Do you mean react-native's built-in Animated library?

Yup I mean by react-native-reanimated sure we don't use it directly into app but this library is used by lot's of other packages e.g react navigation depends upon reanimated
And others as well
Im pretty sure that this could be the root cause for modal freez issue due to blocked touch point app stuck I'm checking what best we can put to solve will update soon

@dhairyasenjaliya ohhhh TIL
@dhairyasenjaliya if the fix is simple / related, let's do it in this PR. Otherwise it'll be best to do it in another PR.

Sure I will check tomorrow morning first

@dhairyasenjaliya it's recommended to write meaningful commit messages. eg: "rename to baseKeyboardSpacer" instead of "implemented suggestions"
Thank you for understanding 🙇♂

sure but this commit covers almost suggestions so write that

@dhairyasenjaliya well, then you could create multiple smaller commits.

alright point noted :)

also @rushatgabhane I have added all suggestions, any further changes are required?

@dhairyasenjaliya I have added the other issue to the issue body and hired you there #10188
Great job, can you also write thorough QA steps for both problems and add some PR body description? thanks!

ah nice sure will add it soon, bit confused about where do I add PR body description's

@dhairyasenjaliya
Details section here:

Just some summary of what, why, how.

@mountiny alright will add details with both issue's QA steps along with details :)

@rushatgabhane I did read that article while I was incorporating the packaging, it seems the article is pretty dated so I wouldn't recommend adding it here what do you say?

@rushatgabhane @mountiny updated the PR description let me know if I missed out any details

hello, @rushatgabhane merged 0.69 main along with other changes :)

Yeah will wrap soon with all changes @mountiny

Lets retest and give this another look! Thanks for the work on this one, getting closer @rushatgabhane @dhairyasenjaliya

@dhairyasenjaliya Is it just me or the app freezes after the keyboard has been closed.
We also get this warning on closing the keyboard: Warning: Overriding previous layout animation with new one before the first began
Steps

Payments page
Click on any payment
Make default
Click somewhere outside to close the password modal

Screen.Recording.2022-08-21.at.2.34.30.PM.mov

Yup that bug i have reported right before working on this PR

Oh yeah, totally forgot about that. Thanks for reminding me.
@dhairyasenjaliya what do you think about the console warning? #10162 (review)

Yeah that warning ⚠  is also related to that close modal issue, I did found one of the old PR where this issue was resolved but now started happening again will share that PR soon

Oh yeah, totally forgot about that. Thanks for reminding me.
@dhairyasenjaliya what do you think about the console warning? #10162 (review)

Yeah that warning ⚠ is also related to that close modal issue, I did found one of the old PR where this issue was resolved but now started happening again will share that old PR number soon

@rushatgabhane added all requested changes

@dhairyasenjaliya this is a iOS Safari only issue and works well on Android - Chrome.
Keyboard is overlapping the button - "Make default payment method"
Screen.Recording.2022-08-21.at.10.05.21.PM.mov

hm this is new let me check

@rushatgabhane I did check the latest code actually it's not a bug
let me explain
so what I debug is when we are testing code in safari and by default, if we don't have a keyboard always open on (command + k), and then we have a condition where there is autofocus the small amount remains at bottom and then you press (command + k) at that time this keyboard avoid is occur

@rushatgabhane I did check the latest code actually it's not a bug
let me explain
So what I debug is when we are testing code in safari and by default, if we don't have a keyboard always open (command + k), and then we have a condition where there is autofocus the small amount of keyboard remains at the bottom and then you press (command + k) at that time this keyboard avoid is occurring

Now test this condition as make sure you always have the keyboard open (command + k) and then try to follow the QA steps
As in real devices by default keyboard is always open

Result with keyboard always open (same as real device)
https://user-images.githubusercontent.com/47522946/185805325-a3861908-bf8c-48a6-adb7-5d2a517c46b1.mp4
Result without keyboard always open
https://user-images.githubusercontent.com/47522946/185805487-42e26fe5-4784-4db7-b865-a2ed99004424.mp4

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@rushatgabhane I checked that bug I dont think this is related here, as the composer never uses keyboardSpacer in the first place

🚀 Deployed to staging by @mountiny in version: 1.1.89-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Istio envoy ratel limiting doesn't work with Ingress gateway

Bug Description
We have Istio ingressgateway and nginx ingress controller installed on the same cluster. Currently we are in the migration process from nginx to istio.
Trying to implement rate limiting for our service using EnvoyFilter, current config is:
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  annotations:
  name: httpbin-inbound-8080
  namespace: httpbin
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.local_ratelimit
        typed_config:
          '@type': type.googleapis.com/udpa.type.v1.TypedStruct
          type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
          value:
            stat_prefix: http_local_rate_limiter
  - applyTo: HTTP_ROUTE
    match:
      context: SIDECAR_INBOUND
      routeConfiguration:
        vhost:
          name: inbound|http|8080
          route:
            action: ANY
    patch:
      operation: MERGE
      value:
        typed_per_filter_config:
          envoy.filters.http.local_ratelimit:
            '@type': type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
            value:
              filter_enabled:
                default_value:
                  denominator: HUNDRED
                  numerator: 100
                runtime_key: local_rate_limit_enabled
              filter_enforced:
                default_value:
                  denominator: HUNDRED
                  numerator: 100
                runtime_key: local_rate_limit_enforced
              response_headers_to_add:
              - append: false
                header:
                  key: x-local-rate-limit
                  value: "true"
              stat_prefix: http_local_rate_limiter
              token_bucket:
                fill_interval: 60s
                max_tokens: 1
                tokens_per_fill: 1
  workloadSelector:
    labels:
      app.kubernetes.io/name: httpbin

It works perfectly fine with nginx ingress or even if we are trying to access the service using internal cluster communication but it doesn't work with gateway.
In our setup we have One gateway for all microservices and virtualservice per service. Istio sidecar injection enabled for all namespaces.
Operator config:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio
spec:
  values:
  values:
    gateways:
      istio-ingressgateway:
        injectionTemplate: gateway
    telemetry:
      v2:
        prometheus:
          configOverride:
            inboundSidecar:
              disable_host_header_fallback: true
            outboundSidecar:
              disable_host_header_fallback: true
            gateway:
              disable_host_header_fallback: true
  meshConfig:
    enableAutoMtls: true
    accessLogFile: /dev/stdout
    defaultConfig:
      holdApplicationUntilProxyStarts: true
  components:
    base:
      enabled: true
    pilot:
      enabled: true
      k8s:
        hpaSpec:
          minReplicas: 3
    egressGateways:
      - name: istio-ingressgateway
        enabled: false
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        label:
          istio: ingressgateway-internal
        k8s:
          serviceAnnotations:
            service.beta.kubernetes.io/aws-load-balancer-internal: "true"
            service.beta.kubernetes.io/aws-load-balancer-backend-protocol: ssl
            service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
            service.beta.kubernetes.io/aws-load-balancer-type: nlb-ip
            service.beta.kubernetes.io/aws-load-balancer-alpn-policy: HTTP2Optional
            service.beta.kubernetes.io/aws-load-balancer-ssl-cert: ${ISTIO_INTERNAL_ACM_ARN}
          service:
            ports:
            - name: https
              port: 443
              targetPort: 8443
              protocol: TCP

Are we missing something? Probably, someone has suggestion why rate limiting doesn't work wit gateway.
Version
$ istioctl version
client version: 1.13.2
control plane version: 1.13.2
data plane version: 1.12.4 (20 proxies), 1.11.5 (10 proxies), 1.13.2 (100 proxies)

$ kubectl version --short
Client Version: v1.21.0
Server Version: v1.21.5-eks-bc4871b

Additional Information
No response

there's no inbound on gateway, please try with outbount or GlobalRatelimit

hi, @zirain , thanks for your suggestion.
I was able to implement rate limiting with this
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: httpbin-inbound
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.local_ratelimit
        typed_config:
          "@type": type.googleapis.com/udpa.type.v1.TypedStruct
          type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
          value:
            stat_prefix: http_local_rate_limiter
            token_bucket:
              max_tokens: 10
              tokens_per_fill: 10
              fill_interval: 60s
            filter_enabled:
              runtime_key: local_rate_limit_enabled
              default_value:
                numerator: 100
                denominator: HUNDRED
            filter_enforced:
              runtime_key: local_rate_limit_enforced
              default_value:
                numerator: 100
                denominator: HUNDRED
            response_headers_to_add:
              - append: false
                header:
                  key: x-local-rate-limit
                  value: 'true'

And it works for all traffic that comes through gateway. But when I set worloadselector  to particular app
  workloadSelector:
  labels:
    app.kubernetes.io/name: httpbin
    ```

Also I've noticed that with ` max_tokens: 10` I have ratelimit 20 per minute. I believe because I have 2 ingress gateway pods. Probably someone knows how to set this value per deployment (or service) but not per pod.

Probably someone knows how to set this value per deployment (or service) but not per pod.

that's why we need global rate limit.

Probably someone knows how to set this value per deployment (or service) but not per pod.

that's why we need global rate limit.

Hi! I'm not sure if the global rate limit solves the problem. I think I am having the same problem. I want to have a rate limit per service and a request amount limit per service. The Global Rate Limit puts a limit for the entire cluster. Is there a way to configure the global one to make this?

@zirain any updates on this?

Hi @zirain! In my case, using the local rate limiter solved my problem. The downside is that you have to create a local rate limiter per service.

You followed the docs here, right? I am doing that but it's not working as this issue reports.

Yep, that one. I remember it was not working because I recreated the cluster and forgot to apply the sidecar injection, so no deployment had the istio proxy sidecar. Make sure that it is running.


Updates LIVD csv file

This PR updates the LIVD table by updating the LIVD csv file.
Changes

Uploaded new csv file: LIVD-SARS-CoV-2-2021-08-11.csv to replace  LIVD-SARS-CoV-2-2021-04-28.csv
Checked LIVD-Supplemental-2021-06-07.csv file against the newly uploaded LIVD-SARS file for possible name changes of tests
Changes related to running generatedocs command

Checklist

Unit test passed
integration test passed
end to end test passed
quick-test all test passed

Testing

[x ] Tested locally?
[ ] Ran quickTest all?
[ ] Ran ./prime test against local Docker ReportStream container?
[ ] Downloaded a file from http://localhost:7071/api/download?
[ ] Added tests?

Fixes
List GitHub issues this PR fixes

#1991

@jorg3lopez it looks good to me from an eyeball perspective, but I would like @RickHawesUSDS to take a look as well since this is a very important piece of our mapping. Also, when you did your local testing, what testing did you use? Did you do a full integration test and run end2end?

@jorg3lopez it looks good to me from an eyeball perspective, but I would like @RickHawesUSDS to take a look as well since this is a very important piece of our mapping. Also, when you did your local testing, what testing did you use? Did you do a full integration test and run end2end?

I did build and then ran testEnd2End. Just did that again a few moments ago, to verify.

@jorg3lopez Please describe the testing you did on this change.

@jorg3lopez Please describe the testing you did on this change.

@RickHawesUSDS These are the tests I ran: gradle test, gradle testIntegration, gradle testEnd2End, and I also did a built which ran all the tasks; everything passed.

@jorg3lopez Did you run  quicktest all?

@jorg3lopez Did you run quicktest all?

@RickHawesUSDS I just did it, everything passed.

@RickHawesUSDS Let me run it again, I want to make sure of it. (./quick-test all)


Feature Request: Markdown Preview

Hi Davo,
Long time no see. I hope you're well & having a great summer.
We had a long discussion a few years ago for mass import/export of txt & Markdown files. Which ended in your granting my wishes & creating tomboytools.
As I predicted, the rise of markdown is unstoppable. Most web content providers static-gens (jamstack.org/generators) are including markdown one by one. The consortium to unify format is also serious now, will take a few years, but no one is waiting.
After Roam Research, dozens of Markdown based knowledge-base/wiki makers like Obsidian & Logseq etc have a huge user-base each. Markdown has basically become Godzilla.
I think we need a new button on the toolbar:
Markdown Preview
This will show a live preview if the note content is markdown.
I would like you to sleep on this & think about it for a few days.
Because I think you will have ideas.
Also I have a lot more to say about the functionality of this little button at the end of toolbar. We can simply call it [.MD].
I am a long time coder & UI/UX guy (multimedia interface design).
I think you can do simple yet genius things with this little button that actually no other application has.
As I said please think about this for a few days and tell me what you think. As this needs a little brewing creatively.
Also I'm using Tomboy-NG on a couple of distros laptops much more than Windows laptop which I rarely turn on nowadays. Fedora will take over as standard from Ubuntu, it runs beautifully on Fedora and another. As does Tomboytools. Also the custom themes (setup colors) make it look stunning in dark mode. As there's no name & export/import themes by colors, that would be a mighty cool feature too bro. So I save #rgb hex values for each theme in a text file. And with the right fonts installed & chilled colors, Tomboy-NG is a honey to look at.
Anyway please think about this request & tell me what you think. Then we can take it further. Because there are several potential strategies possible.
Have a good weekend buddy & thanks again 👍

Hi washere, not ignoring you, I have been travelling in some very remote places.
OK, a markdown preview ?  It would have to be a viewer that is either internal to tomboy-ng or an external one that uses a application that you already have installed.
I am not sure just what you expect from an internal  tomboy-ng markdown viewer, it would make exactly the same mistakes I have made in creating the markdown in the first place. So, by definition, if not in practice, it would look identical to the same note viewed in tomboy-ng format (except from the highlight that md does not support).
In tomboy-ng, I use a widget called KMemo to display a note. At present, I read tomboy's XML, convert it to what KMemo works with and do reverse when saving. So, I could make a MD to KMemo converter I guess. Cheat's way would easy, I already have a MD to XML converter, I'd take the generated MD, convert it to XML, open it with my XML to KMemo converter. Not sure how useful you would find that to be honest.
On the other hand, maybe a stand alone Kmemo based MD viewer would be a useful thing in its own right.
An external viewer might make more sense, on my system here, I have 5 or 6 apps that claim to know what to do with MD, 2 are plain text editors, they don't render it at all, just show the markup characters. Firefox looked promising but first thing it does is ask me what app I want firefox to use to open it. Ocular and Remarkable do a great job of rendering the MD. All the Libre Office apps claim to do MD but history tells me otherwise.
So, perhaps you want me to (eg) make a MD note in /tmp and then launch a predefined app to deal with it ? Should be easy too. What app do you use to look at MD ?  I tend to use github's definition of MD ....
Export and import tomboy-ng's config ?  Yeah, thats easy. its all in one file down in (eg) ~/.config/tomboy-ng. Includes custom colours....
Davo

Hi Davo,
Good to hear from you. Yes I remember you travel lots for work etc, specially in summer.
That's a lot to unpack. I need to think about it more on what you're thinking, they're all important for ways forward.
Our problem, and ironically strength, is that you have to think multi platform. It's not an easy job you have with ng.
Strategically, I think the long term future of ng is markdown incorporation, big time. I don't see how it can be avoided. I think also might be good to rebrand beyond tomboy. I think you could rename this project to whatever you like, and move on. I am not saying abandon tomboy concept or radically change the app, no. But you have made it much better than original. You can call it tomgirl or davoboy or whatever you fancy. But gradually will be free to expand from this basis you have wonderful created. Anyway just an idea. But we're not in Kansas (Tomboy) anymore with ng, but a much better place. I'm early using Windows nowadays. Mainly Linux & your work runs just as good. I even use Linux phones as well as Android. But even if you keep the name ng, we're week beyond the original tomboy even horizon.
Fedora is taking over from Ubuntu as standard, and with latest gnome it's rock solid. That should be the base for testing any Linux apps now. I also been playing with endeavorOS for a year, easy implementation of Arch by a couple of devs (telegram channel & forum) with multi desktop enviro options on login (gnome, plasma etc). But rolling release not point release, au needs updating (easy via welcome panel) every free weeks. Zorin is good for testing Windows-ish apps too, many windows users go there.
I've tested nearly two thousand apps for productivity for my own use. I use just over 50 on Linux, Windows & Android. Multi genre: note taking, outliners, markdown, mindmaps, script writing, ide, etc. Yes on ide systems (Ms vs code, sublime text, atom, etc) there are many Markdown extensions/plugins for each.
Markdown can be learnt in a few minutes, just Google Markdown Cheatsheet & Markdown sample files. Ofc GitHub default readme files are Markdown. Yes GitHub render is just fine.
I suggest getting a few of the best apps for Markdown. Most of the best are free. On Android keep an eye on obsidian (play store) & get community plugins to play & Logseq in GitHub. Also on Play store get Joplin. Joplin also for Linux & Windows are must-haves. Qownnotes on Windows & Linux. MARKOR for Android from F-droid store. I bought typora (Windows Linux) & iAWriter (Windows Android) but they're mainly jazzy interface for fast writing, don't buy, really for professional writers. On Android Epsilon Notes (Russian dev)  is a must have, lifetime license very cheap for pro version, it's the only Android app with dual pane live preview. Joplin (French dev, gave him some ideas he did as features years ago, very popular now) & Qownnotes do dual pane live preview of Markdown on Linux & Windows, try them. Download sample MD files & Cheatsheets. On Android get the free Zettel Notes (nice Indian dev, telegram channel & forum) from play store based on zettelkatsen concept Cross-reference etc, did few features I suggested. Netrinote is nice too on Android. You need markdown sample files with samples of markdown formatting to compare apps. Any markdown render engine you adopt from whatever library your ide systems use is ok. Jotterpad on Android (I bought premium, not subscription) has a stunning render (Singapore guys who do the famous journey app too) of markdown, used also for film script writing, fountain format for Hollywood is variation of markdown, renters both formats.
On Linux, whatever you app store (software apps, yay, discover, Pacman, etc) just search for Markdown, you'll see many apps. Just open several sample markdown files with each to see features & interface.
I think we have to forget about launching external MD apps for ng.
I think you need a standalone MD render for ng. Maybe start with a basic kmemo engine code. Then later expand it or swap it you find something you can plug in & improve & expand later.
I see the problem you're hinting at. Maybe the .MD button can insert a hidden xml type tag to make the note MD eg:
 blahblah note body
And/or also some way to make a note .MD format. No need for switch back to txt as MD with no formatting is txt anyway. Whenever in interface you like, or toolbar or just as part of the function of .MD icon in toolbar. Or completely hidden & auto detected: when MD format characters are detected. Can have an option in settings to disable Markdown render in all notes. Many ways to do, whatever you like. I'm fact all the apps I mentioned above automatically detect & render MD.
But I think a standalone Markdown render by ng is the starting point.
Search the libraries for your ide, I'm sure they're are several Markdown libs to plug in, no need to start from scratch. Also ask on their forum for whatever systems you're using, I'm sure several already making MD libs. It's ubiquitous nowadays.
Yes I uploaded my ng config to Dropbox & drive to backup same day I opened this issue.
Here's some links, sample files, I collect many MD sample files for years now:
https://duckduckgo.com/?q=Markdown+sample+file
https://www.google.com/search?q=readme+site:github.com+filetype:md
https://github.com/laurent22/joplin
Mobile:
https://joplinapp.org/download/
https://www.qownnotes.org/
https://github.com/pbek/QOwnNotes/releases
Linux:
https://flathub.org/en-GB/apps/search?q=Markdown
I need to think more about what you wrote too. But I think ng needs a code engine for rendering MD. I think you need to source the library. There are a few Renner modes. Whatever is easier for you to get a hold of, be it GitHub flavor or the others doesn't really matter, they're all 95% similar, whatever you can get is fine. If kmemo has one, I strongly recommend plugging that in & building it up.
I need to read your post again carefully this weekend. So many questions. Once the basis is chosen by you then the rest falls into place in time. But you have too choose carefully now to make future evolution of the work much easier & more effective.
No need to answer many things I raised, just thinking aloud. But this damn Markdown is the future that can't be ignored. So might as well plan around it. Anyway thanks again Buddy & have a great weekend.

P.S. was swiping above comment on phone with gboard late last night.
Corrected numerous typos etc.

Hmm, I see how a standalone viewer might be useful but they already exist, eg Remarkable or Ocular under Linux, I am sure there are similar things available for Windows and Mac. While it might be fun to make, eg, a new Remarkable, I fail to see what it would do that Remarkable does not already do.
So, your MD button, click it and the  (previously nominated) application opens the markdown version of the current note. You could just use  it to view or, depending on the application, edit it and save it elsewhere as Markdown. What else do you need ?
I value your input here washere, both past and present !  I personally think the thing that holds MD back is its very loose definition. CommonMark is a step in the right direction but still contains several ways of achieving most things and does not do highlighting.
Davo

Hi Davo,
Just saw your comment. Thanks.
I think I didn't make my point clear regarding standalone. I thought you saw 2 ways forward: launch external MD app or render within ng. When I say standalone I meant as part of ng. That's why I said to hunt for pre-existing libraries for your coding platform to plug-in. If you read your first post, you'll see why I thought that standalone means within ng, not to make a separate app! That'll be awful. Nothing you can do will catch up with years of the best of MD apps (most are terrible but several are great) have ahead of you.
No, I mean within ng. Then there's an advantage that they'll never have. What?
NG (currently) As a 3M style Corkboard (Tomboy idea basically) that works well in this day and age (only one IMHO), and in multi platforms too. Then they'll never have what you can achieve.
So, pressing the MD icon shows the MD render, WITHIN the SAME NG FLOATING WINDOW. Not an external app, nor your standalone app which will be still an external app which is why I never meant that.
If you remember my OP here, I said if MD render is implemented in ng, there are very subtle ways which can make it uniquely superior to anything else. But as I said, those I'll outline later if we proceed. No point discussing them now. However the starting point is, clicking the MD button: renders what is called "live view" or "preview" etc, which means showing text formatting in action.
Clicking it again, shows the text again with special MD characters, or the code view.
Now the main point here before anything else is, why I say we should decide on Markdown render implementation?

This is what we call a strategic decision in the software lifecycle.
You either take it now, or don't.

if you do we proceed.

if you decide not, then my estimate, in probable percentage over 50+%, is that in a few years you will implement it.

This is because of several aspects. Productivity apps are moving that way. People who are not giant corporations, are not pouring millions into Markdown apps (obsidian, roam, etc) without any return currently. That's their main business bet.  They see foreseeable advantages over others by starting early.
Users are moving in that direction too.
Platforms, now mostly static generators (blogs etc) are moving that way.
That is predicted to be the backbone of future web.
Ok, so in a couple of years you might decide to do so. What's the damage?
Well you'll be behind two years.

Many enhancements not to mention fixing teething problems early, will be lost, maybe forever. I myself don't know if I'll have time to even check GitHub anymore next year, NVM 2 or 3 years.
And more damage too, basically should've been done before, this is the time. Else ng will fall well behind the curve.

So that's the strategic decision you have to make.
All I can do is advise.
Sure MD or commonmatk doesn't do highlighting & much more. But that's by intention. Whole point is it's minimal. If all those old criticisms were true, Markdown world be long dead as they said. Instead it's taking over the online backbone (NVM just Wikipedia). But that, minimalism, is it's strength.
All the render libraries basically are similar 90+% and that's what matters. That's why I said whatever libraries you choose to plug-in, would be fine. I do not advise coding the render engine from scratch. So in a way there's not much to do.
Just to make further tactical decisions in the post implementation.
However the strategic decision is whether to proceed or not.
I check here every week or two.
As I said in the op, there's no rush.
No need to answer points. These are thinking aloud by you & me.
Let it brew & play around with Markdown apps.
I suggest install a few static-gens that are MD based for your test blogs, or clients, to get a feel.
Most of the best the tech gurus have been blogging in MD for years now, believe me they're not stupid, they made the whole online world in the last two decades.
Unless you see the light, there's no way for anyone to show you and you can make a decision after playing around, for a good while, that's the only & best way. So just pay around with it on one or two static-gens, on Linux not Windows (static-gens take a long time on Windows to setup & debug as I've done many & not really worth it) because they're written for Linux as most Internet servers run on Linux anyway. So, much easier, many are Linux-only anyway.
If not, at least install the good MD apps I mentioned & play with several sample files.
Anyway if you don't do it, someone will do an MD based floating notes notice-board. They're doing all the genres in MD one by one. So take your time to think about this.
Sorry about any typos as swiping on Gboard on phone again.
Have a good weekend buddy 👍

washere,
I have followed this thread with some interest even though MD, per sé, does not interest me in the least. I am looking for text-based notes and see -ng as in a nice niche: formatting, alternate export formats if needed, notebooks -- well beyond simple "sticky notes," shy of the glitzy graphics and incorporation of non-text formats.
I know this issue is for Davo to think about, but you have piqued my interest and hope you and he don't mind my non-programmer intrusion. A couple of questions:

What sort of internal viewer are you thinking about? A dual pane set up like some of the apps you cited? As far as I can see the purpose of a viewer would be (like the preview here) too verify that everything looks fine, but with quick access (another pane, a tab) to the note to edit in -ng. Beyond that the next logical step would be the ability to edit in MD directly.
If I have understood your last post, you are essentially arguing for a shift, ultimately, to an MD format for ng notes. Is that the idea?
I see two separate strands in the apps and arguments. You argue that MD is becoming dominant for website (and other?) development. Your examples of Roam/Obsidian/Zettlr suggest an interest in zettelkasten. Do you see the latter as a possible future for -ng? Do you see MD as essential for both?

Zettelkasten sparked my interest a few years back as I contemplated semi-retirement and what to do with a collection of articles I had used in teaching. COVID and changes in my personal life sidetracked that. However, I am not sure that -ng can (easily)/should go that way, not because it is not useful, but because it would be going head-to-head with dominant players. Better to have its own niche.
More important than MD, but something that requires finding a dev, is someone to produce Tomdroid-ng. It is too bad the original Tomdroid is dead (if still available and useful basically as a standalone), the code apparently undecipherable. However, given that there are now generations of people who do not touch "real computers," Android and iOS apps may be more important to -ng's future.
My two cents. Interested in learning more.

Hi aguador,
I'll answer your 3 questions, briefly because generally that's not the directions in suggesting:

I'm saying to keep things simple.
So simply: the MD button would render the file in its Markdown layout view.
Pressing it again would show the code, as ng does currently with MD files.
I explained this clearly. Just that.

good opportunity to repeat that point again.
No, as I said ng should not try to become an MD app.
Why? Because as I said, there are many with several good ones on Linux, Windows, MacOS, Android. They're years ahead.
As I said ng will never catch up, some have teams working on them, several full time like Obsidian, Roam etc.
As I said ng should remain focused on being a multi floating point notes app. And stick to it's current raison-d'etre.
Then it can progress in it's current evolutionary niche & remain top dog. Otherwise something else will emerge & will use MD to become the dominant "sticky notes" app as you say.

your Zettelkasten idea. Well again that's not about this thread really.
It's a digression. However to answer your question:
Wikipedia sort of is the modern implementation of that. And the Roam revolution with many apps now following, obsidian Logseq Athena etc etc, are basically all doing that. Markdown is the standard lingo, as is for the entering static-gens & new web. But at the heart of all is backlinks, tagging, inclusions & a few other features.
Ng in a way does basic zettelkatsen as well can cross reference notes by auto link creation. But it's not in the league if the apps I mentioned who are different animals really to tomboy & now ng.
Again this is completely a different subject matter & can be a huge are of discussion, irrelevant to tomboy concept. Though certain features can be implemented in ng, however not really what I'm thinking of.
I think ng should remain close to tomboy concept. I'm a way you are disagreeing with me but stating just this point & in fact using my own words sometimes, which I stated clearly before here myself. So no, your projections are not what I mean & are clearly what I rejected.

As for mobile, Android or iOS, I advise against it.
Whole essence of ng is based on multi floating notes. This needs big screen acreage, but tiny phones.
As for further ideas regarding ng incorporating MD live view feature, they're in keeping with tomboy concept, will be unique, very simple but profound. However I'm not going to waste time discussing them if there's no live render of MD. But they'll be specific to tomboy concept.
Anyway, not sure I'll have time to say much more here as life has a habit of interfering. But as I said this thread is for Davo to think about things I mentioned.
Sorry about any typos.
Have a good week everyone 👋

In a few words this thread is requesting:
to have an MD button to render Markdown live preview of a window (if that note has any markdown content, as all apps audio detect md) in the same window.
pressing it again, toggles & shows the raw text as ng currently does anyway. So nothing to code or do.
further, I suggest Davo not to code anything but try to find some markdown preview library to plug-in, which is ubiquitous these days. If he can find one for his coding platform. Asking on relevant coding forums  for whatever system, often brings out people who have or know of such md libs to plug-in.
That's all really.

Ok, just got home & cleaned up Gboard typos somewhat. I had vowed actually to abstain from online presence in all it's forms for lack of time & many other reasons as things proliferate anyway. I think I made my request clear. I'm closing this now as won't have time to regularly check GitHub & don't want to appear rude that I'm ignoring any further replies which I'd never do. Best wishes to all. 🙂

Hey, not so quick washere, still things here to look at. Your clear position -
to have an MD button to render Markdown live preview of a window (if that note has any markdown content, as MD apps & plugins auto-detect md content ie: markdown render lib = MD parser = auto detect format (to put to rest an earlier inquiry)) in the same window.
Thats now clear to me what you want but actually doing it, usefully, is harder. I know no MD parser/render in Pascal, I could use C libraries but at risk of cross platform complications. Remember, a parser alone is not enough, it needs to be show, on screen. I can do that easily, I parse the md to xml (Tomboy Format) and then I parse that into something that KMemo can understand. The last step being rendering. Its all existing code.  But what you would see would be exactly what you see when viewing the note in tomboy-ng. "Exactly" to the best of my ability anyway. That does not achieve anything really.
A more useful approach, would be to use some third party parser and renderer using, by definition, someone else's view of MD. That might highlight short comings in tomboy-ng. But it cannot be integrated into tomboy-ng unless we link it, either statically or dynamically. And there comes our cross platform issues.
Again, I suggest that calling a separate, standalone viewer does achieve what you want. You click that button in -ng, it (behind the scenes) writes a MD file to ~/tmp and calls a app of your choice to look at it. I don't know if its possible  to 'import' a modified version of that MD content back into tomboy-ng, I don't support even the whole CommonMark standard, let alone MD. But that really depends on your use case,  thats not clear to me.
And Tomdroid ?  I have to agree with aguador here, I would really like to have a viable Tomdroid Sync. I did make one, used a rather ugly ssh sync but it did work. However, as soon as I started to use it, it brought back all the memories of bad sync from the Tomboy days. Sadly, Tomdroid has (sync) bugs. I am not willing to fix it, I hate working in Java. Serveral other people have indicated they would like to try but all have walked away. The build process is, apparently, not documented, given the changes that have taken place in Android, it probably would not build with current tools.
Davo

That will be a great bonus.
As long as there's a way to see how it actually looks, hence an MD icon button.
Whatever is easier to start off for you.
Then you'll know what to do slowly & gradually through the coming years as you play with it technically, feature-wise.
Also strategically long term.
The only thing you have to do is hunt around for a good library to plug-in so you don't do the work.
If you find more than one, see which one will be around for the long term. This often depends on the personality of the dev(s)/company, which is why open source is best. Because as coders whatever softwares we choose, it's also a long time investment in our time, which is actually more expensive than money. Plus potential future growth of that software. If you only find one, or none, then no choice. Just find something that's already been made & try it. Then your decisions will gradually emerge after you play around.

Anything happening here will need to be in version 0.38, I need to get 0.37 out reasonably soon for Debian/Gnome issues.
Sorry.
Davo


Diameter of a Binary Tree

🚀 Feature
I am a GSSOC'21 participant.
I can implement this using C++
Have you read the Contributing Guidelines on Pull Requests?
yes
Pitch
Please assign me this.

@neha030 Hi, I assigned you. Happy Coding!😊

I am facing some issue my commits for the issue #2930 is there in #3015.
therefore i request to please review my code there.


Visual Studio hangs on commenting out lines in Razor view

Describe the bug
Today I installed the extension in my VS2022 (17.3.3) and all worked fine. Until I needed to change and comment out some lines in a Razor view in a ASP.Net Framework MVC project. When typing @*, VS automatically adds *@, but the first time it takes a few seconds. Then, the next time, or the third, VS goes from hanging to freezing.
The Razor view I worked on contains if/else statements and thus multiple braces. Which do not get colored, by the way.
After trying and freezing a couple of times, I disabled the extension and commenting out a line in a Razor view worked again. That's why I'm filing a bug report, because I think this is related to the extension.
Re-enabling the extension and trying again, causes the problem again.
To Reproduce
Steps to reproduce the behavior:

Enable RainbowBraces extension
Open an existing Razor view (cshtml)
Try to comment out a few lines by inserting @* at the start of the line to comment.
Then cut the automatically added *@ and paste it to the end of the line
Repeat 3 & 4 until it hangs and freezes.

Expected behavior
I expected the Razor editor to work as before installing the extension.

Does this reproduce with the latest version of the extension?

I am also getting an issue with VS freezing when RainbowBraces is enabled, when opening Razor (cshtml) files.  In my case it's happened with various .cshtml files and seems unrelated to comments since I don't have any comments in this particular file.
I'm running version 1.0.18
I'd be happy to supply some examples if it would help.

@ScottDatafest what .NET version is your project using? Also, are you using the new experimental Razor editor that you have enabled under Preview Features in Tools/Options?

.Net Framework 4.7.2
Not using the new experimental Razor editor.
I am using ReSharper, version 2022.2.2.  (I’ll update ReSharper just to see if it makes any difference.)
Scott A. Clawson
President                         | Datafest Technologies, Inc.http://www.datafest.com/
(801) 261-4608 ext. 2  | AdSystem Bloghttp://blog.datafest.com/
[AdSystem Online Small]
From: Mads Kristensen @.>
Sent: Thursday, September 1, 2022 4:01 PM
To: madskristensen/RainbowBraces @.>
Cc: Scott A. Clawson @.>; Mention @.>
Subject: Re: [madskristensen/RainbowBraces] Visual Studio hangs on commenting out lines in Razor view (Issue #12)
@ScottDatafesthttps://github.com/ScottDatafest what .NET version is your project using? Also, are you using the new experimental Razor editor that you have enabled under Preview Features in Tools/Options?
—
Reply to this email directly, view it on GitHubhttps://github.com/madskristensen/RainbowBraces/issues/12#issuecomment-1234827233, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASOUOTD4OV7CAF3GKZLM7MLV4ERSJANCNFSM6AAAAAAQCMB6UY.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>


chore(NA): Add linux arm64 build

fix: #517

Removed the legacy --cpu build flag for M1, and test it on my local M1 ❯ bazel run //cmd/ibazel --platforms=@io_bazel_rules_go//go/toolchain:darwin_arm64_cgo
I compiled and tested it that I can run it on a linux + arm64 platform - i.e. in a devcontainer using Linux image on M1.

I can also check in the devcontainer config if that's helpful for future development.

## inside devcontainer
# output to verify platform spec
vscode ➜ /workspaces/bazel-watcher $ uname -si
Linux aarch64

# build ibazel
vscode ➜ /workspaces/bazel-watcher $  bazel run //cmd/ibazel --platforms=@io_bazel_rules_go//go/toolchain:linux_arm64

INFO: Analyzed target //cmd/ibazel:ibazel (0 packages loaded, 10258 targets configured).
INFO: Found 1 target...
Target //cmd/ibazel:ibazel up-to-date:
  bazel-bin/cmd/ibazel/ibazel_/ibazel
INFO: Elapsed time: 11.693s, Critical Path: 10.79s
INFO: 72 processes: 3 internal, 69 linux-sandbox.
INFO: Build completed successfully, 72 total actions
INFO: Build completed successfully, 72 total actions
iBazel - Version Development

A file watcher for Bazel. Whenever a source file used in a specified
target changes, run, build, or test the specified targets.

Usage:

ibazel build|test|run [flags] targets...

Example:
...

@achew22  would you help take a look?

Thanks for sending in a PR! I'll trigger a release now

https://github.com/bazelbuild/bazel-watcher/releases/tag/v0.21.1


Add IAM Authentication to dbt-postgres

Contributions

[ ] I am a PM or subject matter expert at dbt who is responsible for this feature.

Where does this content belong?
The new content belongs in this section: https://docs.getdbt.com/docs/core/connect-data-platform/postgres-setup#profile-configuration
This change is connected to https://github.com/dbt-labs/dbt-core/pull/8187.
The PR adds the option of using IAM Authentication for dbt. The change for the documentation should reflect that option.
Link to source material
I have an open PR to address this change: #3799

This issue is not prioritized so adding to 1.8 for us to investigate later. Currently not prioritized in Core repo

The attached issue in the Core repo was closed on April 10th (due to the decoupling of adapters). There was not a new one attached so closing this issue and adding an icebox label if we need to revisit/reopen this.


Zero copy for receive

This is not ready to merge yet, but I'm opening this PR so we can discuss changes related to #134 .

I think the use of Option<MessageReader> in #134 should be eliminated. The only usage of passing None is
https://github.com/pingcap/grpc-rs/blob/8fff94905ca9bccc1875f7f5a9cae7d12aa17196/src/call/server.rs#L79
. Seems that we need some kind of MessageReader that reads nothing.

Why send another pull request? If you are going to "rework" somebody's pull request, better talk about it with the author first.

@BusyJay Because I cannot find you on Slack when I started work on this (I tried to, not once, because as you see I have some questions about your code).
@overvenus said you rarely respond to people online.
I opened this new PR because I consider #134 too old and it's completely diverse with the current master branch.

@BusyJay If you have any thoughts about this PR, don't hesitate to tell me now.

I'm not always online on weekend, better contact me on weekdays if you expect an instant response.

If you are going to "rework" somebody's pull request, better talk about it with the author first.

Now I'm talking to you. Do you have something to say?

I have another question: none of the implemented functions of Read/BufRead for MessageReader are returning Errs. (Some seems to, say, read_to_end returns Err only when read returns Err, read returns Err only when fill_buf returns Err. I assumed these functions not to returning Err at all and you wrote them like that only to fit the interface's functions' type signatures. Then I provided *_directly versions for them. Is this proper? Have I missed anything? The old functions are not removed but changed implementations so there's backward compatibility.
https://github.com/pingcap/grpc-rs/pull/222/commits/c9ae7e9c3385a3d2843cedd629523a11eade3003

Read and BufRead are traits from std library. MessageReader are only used to support serialization/deserialization, where both traits are commonly used. Implementing them by default makes it easier for people to write their own ser/de hooks.

This is basically done. PTAL @BusyJay @overvenus

Fixed, PTAL @BusyJay @overvenus

@siddontang no. I thought there can be some improvements but now not. And PTAL my questions above.

The ideal approach is to use the C++ memory directly, which is not present in #134 . Am I expected to achieve that, or keep the current implementation? (Cus it can be lazily read now and it's better than in-place copy)

And since the destruction of MessageReader is done in Drop::drop, does that mean we can actually read the data without copying if we only call fill_buf_directly without read_directly or read_to_end_directly?

Information get. That looks good

@kennytm https://travis-ci.org/pingcap/grpc-rs/jobs/423982678#L586-L626

@ice1000 The #![allow(renamed_and_removed_lints)] needs to be added to src/lib.rs as well. The two lib.rs belongs to different crates, and their lint settings won't affect each other.

Why it's saying test failed...

The merge of this issue can close #134 .

This shouldn't be my fault..

Wowwww!!! Twavis CI passed, sooo lowely UwU

PTAL @hicqu, thanks!

PTAL @BusyJay

can benchmark result?

please do the benchmark and record in confluence.
/cc @overvenus

Benchmarked in streaming_qps_unconstrained and unary_qps_unconstrained.
QPS: zcp recv means zero receive

Latency: zcp recv means zero receive

Zcp is faster than master with epllsig in rust_protobuf_async_streaming_qps_unconstrained.
Also, epollex is faster than epollsig in gRPC 1.42.
Logs:
zcprecv.epollex.log
zcprecv.epollsig.log
masterrecv.epollex.log
masterrecv.epollsig.log

@kennytm @hicqu @overvenus PTAL

seem zero has no any big difference in unary_qps_unconstrained? @overvenus

Fixed. BTW cargo fmt is not displaying anything locally.

LGTM.

I've finally fixed all the formatting issues from https://travis-ci.org/pingcap/grpc-rs/jobs/443011498

Oh no!

:sob:


ash: Add const STRUCTURE_TYPE to all Vulkan structures for matching with match_struct! macro

Depends on #613
In Vulkan layers extracing a structure based on its s_type is a common operation, but comparing against an enum value and subsequently casting to the right type is verbose and error-prone.
By generating a const STRUCTURE_TYPE with the given value for every Vulkan structure it becomes possible to implement a macro that abstracts this logic away in a safer way.

I'll test and post some build-timings later, see if +2300 trivial trait implementation lines have any effect. As I needed this while writing some Vulkan layers in Rust, the goal is to also submit a minimal layer crate for ash at some point, initially providing just some types before adding better utilities. We'll need to publicize ptr_chain_iter in const and mut variants too.

I'll test and post some build-timings later, see if +2300 trivial trait implementation lines have any effect.

Easy enough to cfg-gate if needed, since it's a new trait.

master @ 61ab543d:
$ hyperfine -p 'cargo clean -p ash' 'cargo b -p ash'
Benchmark 1: cargo b -p ash
  Time (mean ± σ):      7.366 s ±  0.101 s    [User: 8.313 s, System: 0.670 s]
  Range (min … max):    7.248 s …  7.586 s    10 runs

match-structure-type @ eb95efb:
$ hyperfine -p 'cargo clean -p ash' 'cargo b -p ash'
Benchmark 1: cargo b -p ash
  Time (mean ± σ):      7.411 s ±  0.065 s    [User: 8.358 s, System: 0.638 s]
  Range (min … max):    7.305 s …  7.505 s    10 runs

We're talking approx 50ms here, nothing worth cfg()'ing nor worrying for.

@Ralith How do you feel about a hyperfine step for the core crate in CI?

I've heard CI tends to give erratic timings for CPU-bound stuff due to contention, but it might be interesting to try all the same.

@jdtatz only noticing https://github.com/jdtatz/ash/commits/match-structure-type-more-generic just now; any reason this wasn't suggested as a change to cut down on codegen for push_next()? What's the (hopefully positive) compile time improvement?
Or is this all blocking on the recently submitted type support in vk-parse so that we can subsequently drop vkxml use in ash's generator and finally use the validstructs property, to keep push_next() for pNext versus validstructs fields apart so that we can - in the end - get https://github.com/ash-rs/ash/pull/622 in with a proper binding?


Portal doesn't support SSR

What RMWC Version are you using:
6.1.4

Name your build system [Webpack, Rollup...]:
next.js, but should occur whenever SSR is used

Describe the bug with as much detail as possible:
RMWC Portal throws an error on compilation when serverside rendering is used:
ReferenceError: document is not defined

This is due to the ref in the Portal component being initialized with document.createElement('div').
I was wondering because I don't know what this ref is being used for and replaced the <Portal/> with <div id="rmwcPortal"/>. In my usecase This solved the problem and it works with SSR.

I think you used too much Typenscript i gues

Just wanted to bump this. I'm using Portal in SSR, and it still has this issue

Reopened due to this still being an issue