Quoting version numbers in yaml. Switching to official python 3.10

Signed-off-by: Alexander Xydes<EMAIL_ADDRESS>

Codecov Report

Merging #42 (ca1cd45) into main (e8eb3bb) will decrease coverage by 6.61%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##              main      #42      +/-   ##
===========================================
- Coverage   100.00%   93.38%   -6.62%
===========================================
  Files            7        7
  Lines          363      363
===========================================
- Hits           363      339      -24
- Misses           0       24      +24

Impacted Files
Coverage Δ

.../statick_web/plugins/tool/stylelint_tool_plugin.py
85.29% <0.00%> (-14.71%)
:arrow_down:

src/statick_web/plugins/tool/eslint_tool_plugin.py
87.12% <0.00%> (-12.88%)
:arrow_down:

...c/statick_web/plugins/tool/htmllint_tool_plugin.py
98.33% <0.00%> (-1.67%)
:arrow_down:

Continue to review full report at Codecov.

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

I'm not sure why one of the stylelint plugin unit tests is failing. I updated my local stylelint install and ran it manually and got the expected 3 issues from test.css and test.html:
statick-web/tests/tool/stylelint_tool_plugin/valid_package {fix-py310-tests} $ stylelint --config rsc/.stylelintrc *

test.css
 1:5  ✖  Expected single space before "{"   block-opening-brace-space-before

test.html
  9:6   ✖  Expected single space before "{"   block-opening-brace-space-before
 16:21  ⚠  Expected single space after ":"    declaration-colon-space-after

the below error in the github action log suggests some sort of json parsing error, but I'm getting valid json out of the stylelint tool according to jsonlint.com.
WARNING  root:stylelint_tool_plugin.py:111 ValueError: Expecting value: line 1 column 1 (char 0)

After upgrading all the tools the tests are passing for me locally as well.


Getting access modifiers

I was working with a JavaParserClassDeclaration object when i saw that i couldn't get access modifier from this object. It can be obtained from JavaParser, but you probably created this method to wrap that ?
JavaParserFieldDeclaration already has this accessLevel() returning the access specifier. I just updated the method in JavaParserClassDeclaration, JavaParserConstructorDeclaration, JavaParserEnumDeclaration, JavaParserInterfaceDeclaration, JavaParserMethodDeclaration.

Well, this seems very reasonable to me.
Thanks for catching this!


Test Mocks are not usable by consumers

The test mock setup is not accessible by consumers.
Currently, these test helpers live inside of the tests folders and they are not shipped to NPM.
Even if they were shipped to NPM, that's not the right place to have test helpers to be consumed by others.
If an addon wants to ship a test helper, they should have them at addon-test-support.
For more references, check other addons. One example is ember-power-select.

Hi @josemarluedke!
Thanks for the reference. I will have a look at it and do the required changes this week or the week after. Being honest, there is a big room of improvement to improve testing support, so, I will be glad to jump into it.
Best regards,
Daniel.

Hi @josemarluedke,
I am sorry this took longer than expected. I just released a version with the test helpers available and some other fixes. I hope it is usable enough outside of the addon scope, since I created the helpers only to write tests for the addon. I might need to review how to make them more general and usable.
I am going to close the issue, but feel free to open it again if the resolution is not good enough.
Best regards,
Daniel.


Increase max lines of ItemName in grid view

maybe you consider it unnecessary, but some users need it, like me, if I have many files with a slightly long name, and they have a number at the end, and I want to interact with some with a specific number, I would have to be hovering to each of them to see their full names, and it would be tedious.

i think this can merge with #997


Referent does not get Referral bonus after 3 active referrals

Refer another wallet so this will get the Referent bonus
From the referent wallet refer additional 3 wallets and trade.

Expected behaviour
Referent wallet should get the Referral bonus of 20%
Actual behaviour
Referent remains with the Referent bonus of 10%

I'm happy to change this but it was by design (removed bug):
https://github.com/get10101/10101/blob/8c46fb0fbe00bcc6eb58071f13d5bd11b41dab6d/coordinator/src/referrals.rs#L90-L103

I'm happy to change this but it was by design (removed bug-label):
https://github.com/get10101/10101/blob/8c46fb0fbe00bcc6eb58071f13d5bd11b41dab6d/coordinator/src/referrals.rs#L90-L103

So it was a design bug then 😉


Answers Updating

Hi there,
previously I faced a problem of updating the ChatterBot answers when its could not find the right one for a given question, my chatterbot was trained using data from the ChatterBot dialog corpus .
Then I decide to create a chatterbot database from scratch by creating empty database and inserting the question and the the answer one by one using the example "learning_new_response.py".
the application works like this:
type something to begin ...
me: hi
chatterbot: Is "hi" a coherent response to "hi"?
me: no
chatterbot: please input the correct one
me: Hello Dear!
chatterbot: Responses added to bot!
..............................   and so on until I enter, let say 5 questions and answers. Then if I choose a pre-definde question it will choose a wrong answer.
for example if I write "hi" the chatterbot will respond : Is "I am good thank you." a coherent response to "hi"?
I wondering what is going wrong here! ?
by the way, if I open the created database I can find all the questions with the right answers but I don't know why it chooses a different answer even when I use the BestMatch as logic adapter.
bellow is my code that has been used:
from chatterbot import ChatBot
from chatterbot.trainers import ChatterBotCorpusTrainer
bot = ChatBot(
    "Terminal",
    storage_adapter="chatterbot.storage.SQLStorageAdapter",
    trainer = "chatterbot.trainers.ChatterBotCorpusTrainer",
        logic_adapters=[
        {
            "import_path": "chatterbot.logic.BestMatch",
            "statement_comparison_function": "chatterbot.comparisons.levenshtein_distance",
            "response_selection_method": "chatterbot.response_selection.get_most_frequent_response"
        }
    ]
)

def get_feedback():
    text = input()
    if 'yes' in text.lower():
        return False
    elif 'no' in text.lower():
        return True
    else:
        print('Please type either "Yes" or "No"')
        return get_feedback()
print("Type something to begin...")

while True:
    try:
        request=input()
        input_statement = bot.input.process_input(request)
        temp1,response = bot.generate_response(
            input_statement,1
        )
        bot.output.process_response(response)
        print('\n Is "{}" a coherent response to "{}"? \n'.format(response, input_statement))
        if get_feedback():
            print("please input the correct one")
            request1=input()
            response1 = bot.input.process_input(request1)
            bot.learn_response(response1, input_statement)
            print("Responses added to bot!")
    except (KeyboardInterrupt, EOFError, SystemExit):
        break

Hi @gunthercox @Aljumaili85
I have tried this code but got an error
**

input_statement = bot.input.process_input(request)
AttributeError: 'ChatBot' object has no attribute 'input'.

**
Can you please help me how to get rid of it.
Many thanks

It a problem of incompatibility of the given code and the installed ChatterBot version. try to install the latest ChatterBot and try again.  meanwhile i will try to see whats wrong

Hi @Aljumaili85
Thanks for the prompt response.
Upgraded the chatterbot version.
I have the following errors now:

DEFAULT_SESSION_ID = bot.default_session.id
AttributeError: 'ChatBot' object has no attribute 'default_session'

Cannot find reference 'input_function' in 'utils.py' less... (Ctrl+F1)
Inspection info: This inspection detects names that should resolve but don't. Due to dynamic dispatch and duck typing, this is possible in a limited but useful number of cases. Top-level and class-level items are supported better than instance items.


Candy should have an easier way to install and use via package management

I have an existing web application which uses npm+bower+grunt, I and would like to add Candy to it.  I found that this was not easy, and I believe this process could be greatly simplified.
If you want to include Candy in an existing node+grunt app, you have to something like the following:
1. Add Candy to your package.json
Add "candy": "candy-chat/candy#3bad2bc2ca" to your package.json. This will cause npm to download the github repo when npm install is performed. I used commit #3bad2bc2ca as a tag.
2. Install Candy's node modules and run Candy's grunt build
Because there are no dist assets in the github repo, you have to run npm install and grunt build on behalf of Candy inside ./node_modules/candy. For the npm install, you can use grunt-auto-install, and for the grunt build, you can use grunt-subgrunt.
After you add and configure grunt-auto-install, whenever you run npm install at your root application's scope, npm install will also be run inside the ./node_modules/candy folder for you. This will install the node modules required by Candy in preparation for the grunt build.
After you add and configure sub-grunt, you can configure a grunt task at your root application's scope to trigger grunt jobs in the ./node_modules/candy folder. This will build all of the JS bundles that Candy needs.
2.1 Install and configure grunt-auto-install
Install the package
npm install grunt-auto-install --save-dev

Configure your Gruntfile.js
grunt.initConfig({
  auto_install: {
    local:{},
    run: {
        options: {
            cwd: './node_modules/candy',
            stdout: true,
            stderr: true,
            failOnError: true,
            npm: true
        }
    }
  },
});

grunt.loadNpmTasks('grunt-auto-install');

Then, at your application root, you can test this by invoking the grunt command grunt auto_install:run. Candy's node modules should then be installed in ./node_modules/candy/node_modules
2.2 Install and configure grunt-auto-install
Install the package
npm install grunt-subgrunt --save-dev

Configure your Gruntfile.js
grunt.initConfig({
  subgrunt: {
    run: {
      projects: {
        'node_modules/candy': ['build']
      }
    }
  }
});

grunt.loadNpmTasks('grunt-subgrunt');

Then, at your application root, you can test this by invoking the grunt command grunt subgrunt:run. Candy's JS files will then be generated.
Conclusion & Recommendation
This is probably more complex than it should be. Step 2, 2.1, and 2.2 above could be completely removed if Candy would include pre-built or "dist" assets in it's repo. I recommend that Candy publish pre-built assets as a part of each build pushed to Github.

if Candy would include pre-built or "dist" assets in it's repo. I recommend that Candy publish pre-built assets as a part of each build pushed to Github.

We explicitly do not do this because it is not a sensible approach to distributing software. Something along the lines of "subgrunt" or preferably a standard approach for packaging Javascript modules, is consistent with the requirements of developing, building and distributing software. Unfortunately Javascript has a very immature ecosystem, so these things are still being (re-)invented.
For now, I would recommend contributing the above as documentation.

have a look at other packages needs to build. such as bootstrap.

We do not bundle any jQuery, @zh99998, you can use whatever version you like.

just release a compiled tar.gz format package here will help a lot.
npm support tarball url as dependency, but not support zip

Like the tarballs at https://github.com/candy-chat/candy/releases, @zh99998?

@benlangfeld yes I'm talking about here
https://github.com/candy-chat/candy/releases
now only released compiled package in zip format, no tar.gz

The release config is at https://github.com/candy-chat/candy/blob/master/Gruntfile.js#L247-L259. Would you be able to prep a PR which releases compiled tarballs too, @zh99998?

sorry I tried several times but can't build it.....
seems due to this https://github.com/dylang/grunt-notify/issues/118


Fix/AWS Multipart Hashes

Here's a first draft of changes to handle hashing multipart uploads to match the ETag on S3. I'm really not sure about the structure of the change, let me know if you'd like it implemented some other way.
I wasn't able to get the live test running locally but I think it should pass. I tested with a project of mine and it seems to work.
Gzip support is not implemented at this point.
Fixes #201

Thanks for putting in the work on this! I ran the test suite locally on your branch the the suite is passing.
It would be really nice to maintain support for gzip, that should be especially relevant for projects with large files. Is it feasible to make that happen?

Ok, I think this is ready for another look. Pretty significant changes were necessary to implement the gzip stuff because of the way the Class inheritance is set up.
Do you mind if I squash the branch?

Very nice work with moving this forward! I had a few more comments.

Thanks very much for the thoughtful and constructive review -- I've made the changes generally as suggested. Let me know what you think.


Skip mark entries

(ugh. renaming the branch reset the PR. never again...)
I flipped the logic so it might be clearer now.
We always mark entries, unless we call org-read-date.
(defun org-journal--org-read-date (orig-fun &rest args)
  "In the case where the calendar is opened to input a timestamp, don't mark entries."
  (progn
    (setq org-journal-allow-mark-entries nil) <----- turn it off temporarily
    (unwind-protect
        (apply orig-fun args)               <------- (calendar) gets called in here, and therefore org-journal-mark-entries
      (setq org-journal-allow-mark-entries t)))) <---- turn it back on

This looks reasonable. I still don't quite understand why we have to disable marking explicitly for org-read-date, since the function that does the marking is disabled anyway. But if you say it's necessary, I'll trust your assessment.
But since the variable is supposed to be configured by the user, it should be a defcustom, not a defvar.

@dppdppd can you make the suggested correction so we can merge?
Then I would squash this with the title "Skip marking calendar entries for date input"


civo: 1.0.53 -> 1.0.54

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/civo/cli/releases.
meta.description for civo is: CLI for interacting with Civo resources
meta.homepage for civo is: https://github.com/civo/cli
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.0.54 with grep in /nix/store/9rqsafk8rmbcjk3lmf8b2byhr6grahsp-civo-1.0.54
found 1.0.54 in filename of file in /nix/store/9rqsafk8rmbcjk3lmf8b2byhr6grahsp-civo-1.0.54

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
civo

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/9rqsafk8rmbcjk3lmf8b2byhr6grahsp-civo-1.0.54 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A civo https://github.com/r-ryantm/nixpkgs/archive/88114e926ba197f1584ed8e3eddee15a93389881.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/9rqsafk8rmbcjk3lmf8b2byhr6grahsp-civo-1.0.54
ls -la /nix/store/9rqsafk8rmbcjk3lmf8b2byhr6grahsp-civo-1.0.54/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

civo

Maintainer pings
cc @berryp for testing.

Result of nixpkgs-review pr 233271 run on x86_64-linux 1

1 package built:

civo


Adding collateral enabled checks for redemption collections might make users uncapable of redeming their funds.

[MEDIUM] - Adding collateral enabled checks for redemption collections might make users uncapable of redeming their funds.
This PR is intended to fix the bug described in this Sherlock issue. However, the Sherlock report is actually wrong and the vulnerability described must not be considered as an issue in the first place, so the collateralEnabled check should not be added on collecting redemptions.
Enabling/disabling collaterals allows the protocol to add or remove supported collaterals, not to be used under uncertain situations, such as a hack. In such type of situations, the isRedeemPaused check can be enabled to prevent users from redeeming if something wrong is currently  happening.
The problem with adding the collateralEnabled check here is that if Ubiquity decides to disable a collateral in the future, some redemptions might be already queued, so users won't be able to withdraw their funds.
Recommendation: Remove the collateralEnabled check for collecting redemptions.
Originally posted by @0xadrii in https://github.com/ubiquity/ubiquity-dollar/pull/894#discussion_r1572571068

The isRedeemPaused works pretty much the same way as collateralEnabled (one, two). So if some user requested collateral via redeemDollar() but hasn't collected it (because the protocol paused redeems) then the user also wouldn't be able to collect collateral regardless of whether the collateral is enabled or disabled.
Ideally we should remove both collateralEnabled and isRedeemPaused checks for collectRedemption() to allow users to withdraw any time. But since the protocol is in its early stage I would prefer things to be:

Highly centralized
With as many safety checks as possible

I understand your concerns but this issue is more about centralization risks. We'll gradually move to removing unnecessary safety checks.
I would move this issue to some metatask like "centralization risks" which would have issues like:

Transfer ownership (and admin role) to multisig or governance
Allow users to withdraw funds from the pool at any time

I agree with you, although from my point of view even if they work the same way they should be considered as two different mechanisms. From a security perspective, the pool will be protected by directly pausing redeems. But yes I get your point, and probably this won't be a problem for a long time until a collateral needs to be disabled , so I also agree that it could be handled as a centralization risk task and if needed then add it as a new feature.


introduce page of supporting guidance, plus an image

Branch to check conflicts

Branch to check conflicts

Hmm, no.  I don't think we need this practice.  Let's find out how to locally resolve the conflicts.


Measurement Panel broken in v2

projectionStream is not a function during centroid calculation
called here:
  centroid = d3_geoPath(context.projection).centroid(entity.asGeoJSON(graph));

Update: this issue looks like it has morphed, the panels 'work' now but are instead reporting that they cannot access the localized label text.

This issue has been fixed already.


docs(@angular/cli): Updates global library instructions

@filipesilva, follows up comments on https://github.com/angular/angular-cli/pull/6294

@dave11mj LGTM aside from the nit, thanks for taking the time to do this 👍

No problem ~ ^^, and I agree that sentence could have used a little re-writing so I updated the commit to add the suggestion! :D


fail to parse with no error

this chart does not return any template
apiVersion: batch/v1
kind: Job
metadata:
  name: eg-{{.Values.cfg.tenant}}-gateway-helm-certgen
  namespace: {{ .Values.cfg.controllerNamespace }}
  labels:
    helm.sh/chart: gateway-helm-latest
    app.kubernetes.io/name: gateway-helm
    app.kubernetes.io/instance: eg-{{.Values.cfg.tenant}}
    app.kubernetes.io/version: "latest"
    app.kubernetes.io/managed-by: Helm
  annotations:
    "helm.sh/hook": pre-install, pre-upgrade
spec:
  backoffLimit: 1
  completions: 1
  parallelism: 1
  template:
    metadata:
      labels:
        app: certgen
    spec:
      containers:
      - command:
        - envoy-gateway
        - certgen
        env:
        - name: ENVOY_GATEWAY_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: KUBERNETES_CLUSTER_DOMAIN
          value: cluster.local
        image: {{ .Values.eg.certgen.image }}
        imagePullPolicy: IfNotPresent
        name: envoy-gateway-certgen
      imagePullSecrets: []
      restartPolicy: Never
      securityContext:
        runAsGroup: 65534
        runAsNonRoot: true
        runAsUser: 65534
      serviceAccountName: eg-{{.Values.cfg.tenant}}-gateway-helm-certgen
  ttlSecondsAfterFinished: 30

value.yaml
eg:
  envoyproxy:
    replicas: 2
    image: hub.comcast.net/k8s-eng/envoyproxy/envoy:distroless-v1.29.3
    resources:
      limits:
        cpu: 1000m
        memory: 1024Mi
      requests:
        cpu: 256m
        memory: 256Mi

  shutdownManager:
    image: hub.comcast.net/k8s-eng/envoyproxy/gateway:v1.1.0
  rateLimit:
    image: hub.comcast.net/k8s-eng/envoyproxy/ratelimit:master
  certgen:
    image: hub.comcast.net/k8s-eng/envoyproxy/gateway:v1.1.0
  gateway:
    replicas: 1
    image: hub.comcast.net/k8s-eng/envoyproxy/gateway:v1.1.0
    resources:
      limits:
        cpu: 500m
        memory: 1024Mi
      requests:
        cpu: 100m
        memory: 256Mi
  testDeployment:
    image: hub.comcast.net/k8s-eng/gcr.io/k8s-staging-gateway-api/echo-basic
    resources:
      limits:
        cpu: 200m
        memory: 1024Mi
      requests:
        cpu: 100m
        memory: 256Mi
cfg:
  tenant: "tenant2"
  tsfService: "service1"
  rail: "public"
  lbIPs: "<IP_ADDRESS>"
  controllerNamespace: tenant2-ns1
  namespaces:
    - tenant2-ns1
    - tenant2-ns2

Hi @christiancadieux!
This library doesn't support hooks, only release manifest templates. Your chart only has a hook, so that's not part of the chart release and thats why it returns "empty".
I you would want to be part of the final manifest release, remove the "helm.sh/hook": pre-install, pre-upgrade annotation.

I released v0.7.0 with the option to render hooks. In case you think would be better than removing the annotation for your use case.

great - thanks


SCRIPT5007: Unable to get property 'config' of undefined or null reference

SCRIPT5007: Unable to get property 'config' of undefined or null reference
Error: File: jspdf.min.js, Line: 273, Column: 21893
jspdf = new jsPDF('p','pt','letter');
var margins = {top:80, bottom:60, left:40, width:522};
        jspdf.fromHTML(source, margins.left, margins.top, {'width':margins.width}, function (dispose) {jspdf.save('RequestConfirmation.pdf');}, margins);

It gives blank document on IE11 and IE10. (Passing HTML div as a source)

This error "Unable to get property 'config' of undefined", it solve with the jspdf.js file, not with the jspdf.min.js file. It worked for me.


Could you please share the pretrain weights after stage 1?

Hi, we upload all the pretrained weights to hugging face, please find them here.


fix(lighthouse-service): calcscore missing error msg (#5142)

Signed-off-by: RealAnna<EMAIL_ADDRESS>

This PR

adds an error message to calcscore

Related Issues

Fixes #5142

would it also make sense to add a message this and that case?


Atom lags and crashes with no crash report

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
When using Atom, every 5 seconds the editor will lag for ~2 secs. (If I watch the cursor, it will blink 5 times, then pause 2, then start again.) Obviously see this when coding -- lag then type appears. If I leave the editor open, in the background while I'm working in other apps, it will eventually crash, after ~20mins.
Worth noting:

I have latest stable release installed (1.20.1), with only the core packages installed and enabled.
I've wiped my machine of Atom and all hidden files and reinstalled. Same result.
I've tried safe mode. Same result.
I've tried clearing saved state. Same result.
I've reset to factory settings. Same result.
Following a crash, I've looked in Console for a crash report. There is never one.

Steps to Reproduce

Open Atom
Start working in any file, or even just working in the app at all
Notice the lagging
Leave app open, wait for the crash after ~20 mins

Expected behavior: I would expect to work in the editor with no lag and no intermittent crashes.
Actual behavior: It lags every 5 secs, for 2 secs; crashes after being open for ~20 mins.
Reproduces how often: Every time I have it open.
Versions
Atom    : 1.20.1
Electron: 1.6.9
Chrome  : 56.0.2924.87
Node    : 7.4.0
Additional Information
Video: Watch cursor then lag when typing.
https://bazaarvoice.box.com/s/9a10ulqdsak8i0e8ul5qbr1i3t8ffqzq

Thanks for the report - do you happen to have a .git folder in your home directory?
ls -ld ~/.git

Yes, there is a .git and .gitconfig file.

Thanks for confirming - I'm pretty sure that's the cause so if you don't need the directory, go ahead and delete it and let us know if you still see the lag.
Relatedly, this issue with large repos (where initializing a home directory as a repo is an example of that) should be resolved in an upcoming release /cc https://github.com/atom/github/pull/1153.

That was it. Thanks, @rsese.


syntax highlighting for code snippets

similar to https://github.com/solid/solid/pull/88

Thanks! :)


Fixed Kubernetes task does not use specified version issue

Fix for issue
https://github.com/Microsoft/vsts-tasks/issues/7515

Anumita, can you please push this change?


Tenant UI developer documentation additions

Should catch up on a few Tenant UI developer notes (maybe spawn other tickets if any of these are too big, but as part of this ticket determine direction for all of these at the least)

In https://github.com/bcgov/traction/tree/develop/services/tenant-ui#internationalization add some details (link to a readme in the appropriate folder?) about using the scripts Akiff developed for filling things in etc.
Add details about unit tests, coverage, running, etc in https://github.com/bcgov/traction/tree/develop/services/tenant-ui#developing
Move UX documents to a subfolder in https://github.com/bcgov/traction/tree/develop/services/tenant-ui/docs. Or check with Emiliano if they are appropriate to have in the repository (or should move to other storage)
Determine if we want to add more videos/need to adjust existing to the https://github.com/bcgov/traction/blob/develop/docs/USE-CASE-ONBOARD.md document. Also if those videos should be hosted elsewhere (YouTube?). Check with Emiliano. If any action on that, create a new ticket.
Documentation on ngrok usage in Docker scripts for Traction
Documentation on email mock image that can be used locally and how to use it

Gavin Primary


Doc Feedback: multiple guidelines for configuring IS as key manager

Location : https://apim.docs.wso2.com/en/next/install-and-setup/setup/distributed-deployment/configuring-wso2-identity-server-as-a-key-manager/
https://apim.docs.wso2.com/en/latest/install-and-setup/setup/distributed-deployment/configuring-wso2-identity-server-as-a-key-manager/
There are two different guidelines for configuring IS as keymanager through wso2 docs, only one of them are latest and one of them labeled next, which of them should one follow as they are completely different?

Now Both the docs are updated with the simmilar content.
The Docs labeled as next corresponds to the docs for the next APIM (APIM 4.0.0) release.
So it is recommended to refer to the latest docs  (Corresponds to APIM - 3.2.0).

Will close the issue as per previous comment.


Error handler via bot.catch() does not get called.

Hi
We have a problem that the customer error handler used by calling bot.catch(myErrorHandler) is not called when a getUpdates() throws an error.
Such an error can be the following:   Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running).
In your documentation here you describe how to install a custom error handler but that does not really work. or did i do something wrong ?
The question is how to access such erros because currently this does not seem possible.
Here is an example code in deno to reproduce the problem. deno version used is 1.25.0
import { Bot } from "https://deno.land/x/grammy/mod.ts";

// Create bot object
const bot1 = new Bot(""); // <-- place your bot token inside this string
const bot2 = new Bot(""); // <-- place the same token here again

const startBot = (bot: Bot, name: string) => {
  console.log(`[${name}] starting`);
  console.log(`[${name}] adding custom error handler`);

  // TODO: this does not get called
  bot.catch((error) => {
    console.log(`[${name}] got error from custom error handler`, error);
  });

  // Listen for messages
  bot.on("message:text", (ctx) => {
    console.log(`[${name}] got text msg`, ctx.message.text);
    ctx.reply(`Reply from ${name}`);
  });

  bot.start();
};

const handleUpdates = async (bot: Bot, name: string) => {
  console.log(`[${name}] getting updates`);
  while (true) {
    try {
      const update = await bot.api.getUpdates();
      console.log(`[${name}] got update`, JSON.stringify(update));
      await new Promise((f) => setTimeout(f, 1000)); // sleep
    } catch (error) {
      // this works fine
      console.error(`[${name}] got error from catch`, error);
    }
  }
};

startBot(bot1, "bot1");
startBot(bot2, "bot2");
handleUpdates(bot1, "bot1");
handleUpdates(bot2, "bot2");

Run it with deno run --allow-net --no-check --allow-env index.ts
Here are the logs i am getting. Notice that the got error from custom error handler message is not there indicating the customer error handler is not called.
[bot1] starting
[bot1] adding custom error handler
[bot2] starting
[bot2] adding custom error handler
[bot1] getting updates
[bot2] getting updates
[bot2] got update []
[bot1] got error from catch Error: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running)
    at ApiClient.callApi (https://deno.land/x/grammy@v1.1.4/core/client.ts:234:19)
    at async handleUpdates (file:///home/name/deno/index.ts:29:22)
[bot1] got update []
[bot2] got error from catch Error: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running)
    at ApiClient.callApi (https://deno.land/x/grammy@v1.1.4/core/client.ts:234:19)
    at async handleUpdates (file:///home/name/deno/index.ts:29:22)

Telegram does not allow you to poll updates from two places. It makes no sense to handle this error programmatically.
Generally, the errors thrown by getUpdates calls can only mean two things:

Your code is incorrect. In that case, grammY will crash, so you can fix the problem. It makes no sense to handle this programmatically in userland code.
Your code is correct, but there are temporary problems such as network issues, flood waits, server downtime, or internal server errors by Telegram. In all of these cases, grammY will handle the error internally fully automatically according to the specification, and then retry the operation. It makes no sense to handle this any differently in userland code.

Thanks for your reply. Actually we have a platform where we run bots and we also have 2 deployment stages for this platform. When someone let's say in staging uses a bot with a token that is running in production we get theses errors and send them per email so someone would fix it and stop one of the bots or use a different token. so we actually make use of these errors.
Is there anything that can be done such that the user of the library gets the internal errors that grammy handles as well ?

Sharing bot tokens between environments is a flawed approach. You may potentially lose some updates that were sent to a bot running in production. In addition, you're actively crashing the instances running on production by doing that. The solution to your problem is to not share bot tokens, which will avoid these errors entirely.
When grammY crashes (case 1 above) the call to bot.start will reject. Hence, you could get access to the error like that:
bot.start()
  .catch((err) => {
      console.log("Houston, we have a bug:", err)
  })

When grammY retries a request to getUpdates automatically, you won't be able to handle the error.

We have the linting rule already thanks :) the example i sent is just a small demonstration of why it does not work. I know it's a mistake to share tokens between envs but we can't stop the people using our platform from using such tokens twice. So we need access to such errors. In this example i tried to implement what you suggested by catching the errors on start but it still does not work. I don't get any errors. Funny thing is that i still get replies from both instances at the same time
import { Bot } from "https://deno.land/x/grammy/mod.ts";

// Create bot object
const bot1 = new Bot(""); // <-- place your bot token inside this string
const bot2 = new Bot(""); // <-- place the same token here again

const startBot = (bot: Bot, name: string) => {
  console.log(`[${name}] starting`);
  console.log(`[${name}] adding custom error handler`);

  // TODO: this does not get called
  bot.catch((error) => {
    console.log(`[${name}] got error from custom error handler`, error);
  });

  // Listen for messages
  bot.on("message:text", async (ctx) => {
    console.log(`[${name}] got text msg`, ctx.message.text);
    try {
      await ctx.reply(`Reply from ${name}`);
    } catch (error) {
    console.log(`[${name}] got error from ctx.reply`, error);
    }
  });

  bot.start().catch((error) => {
    console.log(`[${name}] error from catch` , error);
  })
};

startBot(bot1, "bot1");
startBot(bot2, "bot2");

You cannot rely on this detection. It is a best-effort approach implemented by Telegram. As I said before, it is a bad idea to build any software of top of these errors. Consider adding checks that make sure every token is only used once.
Alternatively, you could use webhooks. They have much less overhead especially in setups that run many bots on the same code. Also, they don't suffer from your current problem.

Webhooks is on our TODO list. For us there is currently no way to stop people from using the same token twice espicially because there is a seperate database for each environment and people could just use a token in staging that is being used in production. So from what you say there is no way that you at least notify the users of the library that an error happended ? I mean i am sure there are some people who are interested in knowing which errors are happending with their bots right :) ?

It's not feasible for us to crash because the platform is centered around around the idea of a bot runner. it's also difficult to prevent users from using the same token for their bots because we use two separate environments. i really think it's reasonable if the library users could have some way of getting notified about the internal errors that occur. grammY can still handle the error internally of course but notifying the library users would be also a good idea and it's really simple to implement with an event emitter that emits errors don't you think ?

Sharing bot tokens between environments is a flawed approach. You may potentially lose some updates that were sent to a bot running in production. In addition, you're actively crashing the instances running on production by doing that. The solution to your problem is to not share bot tokens, which will avoid these errors entirely.
When grammY crashes (case 1 above) the call to bot.start will reject. Hence, you could get access to the error like that:
bot.start()
  .catch((err) => {
      console.log("Houston, we have a bug:", err)
  })

When grammY retries a request to getUpdates automatically, you won't be able to handle the error.

Hey @KnorpelSenf, is there a way to get the same catch if using the runner package?

it's really simple to implement

The problem isn't that this is too complex to implement. I don't see the point why we should add any features that encourage bad design.

is there a way to get the same catch if using the runner package

I believe that the promise task on the handle returned by the run function will reject, but I haven't tested this because, well, it's just not a good idea to write a bot that way :)
I think there isn't anything else to add to this, so I'll close this issue. If you have any further comments or questions, feel free to leave them here (or reopen)!


Add NPM package

Fixes #3
The basics should make sense but there are some possibly unexpected changes:

I called it @dmsnell/diff-match-patch because https://github.com/JackuB/diff-match-patch took the top-level diff-match-patch name on NPM. Feel free to rename it.
I deleted the minified code, because it's not really necessary in an NPM package. Any project that needs it will already have tools to do this.
I added zora to run the tests, it's lightweight and fast

I'd like to also add the types from https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/diff-match-patch but they're technically MIT. The types are very simple, and there's probably no legal issue with copying them, but I don't know if you want to deal with potentially mixed licensing 🤔

I wasn't sure what to do with the readme in the NPM package, so I left it out. https://github.com/JackuB/diff-match-patch ships what I think is a copy of the wiki API from google.

@TheSpyder I'll be on vacation during the next week, but I'll try and get to this once I'm back. some initial thoughts:

are we sure this export change leaves existing code and dependencies in a good state?
I wonder if we can stage this in multiple pieces. one thing I thought would be nice is to start building the minified and compressed version of the library in Github Actions. it'll be nice to leave things in as they are for existing projects, but if we can remove the need to manually run build steps that would be awesome.
despite being slower and possibly silly, I'd probably prefer leaving major changes like revamping the tests or removing the compressed/minified version of this out of a PR to start publishing an npm package. I get quickly overwhelmed and find it hard to focus on changes that do many things at once.

this is impressive I can tell even at a glance. great work.

are we sure this export change leaves existing code and dependencies in a good state?

Hard to say. For anyone using the NPM package, it's equivalent, but I did see one person in the issues of that repo asking for a simple change to keep it running in browsers where a module global isn't available. I'll add that.

I wonder if we can stage this in multiple pieces. one thing I thought would be nice is to start building the minified and compressed version of the library in Github Actions. it'll be nice to leave things in as they are for existing projects, but if we can remove the need to manually run build steps that would be awesome.

That's definitely a good thought. I wanted to get something published for an internal deadline, but I might link the project to a branch of my fork rather than try to rush this.

despite being slower and possibly silly, I'd probably prefer leaving major changes like revamping the tests or removing the compressed/minified version of this out of a PR to start publishing an npm package. I get quickly overwhelmed and find it hard to focus on changes that do many things at once.

Fair point. I'll roll back the branch to remove the test change commit and wait until the NPM package settles to submit it.
I removed the minified version mostly I figured both should be equivalent and I don't have the tools installed to generate it from the uncompressed changes I made. I can bring it back and set the NPM package to publish without it.

this is impressive I can tell even at a glance. great work.

thank you 😁

@dmsnell I've done a few things:

rolled back the test change (and kept it + added types on a branch we'll use for our release).
made some changes to attempt to keep the browser compatibility intact.
restored the compressed version, although it doesn't have the patches applied so the two files have diverted for the moment.

@dmsnell will you have time to look at deploying this to NPM soon? I'm not trying to pressure you, just curious.

will you have time to look at deploying this to NPM soon? I'm not trying to pressure you, just curious.

sorry @TheSpyder - I should have anticipated this, but I'm currently held up by some work in the current WordPress release, which is happening right now. please allot me another week and I'll try to prioritize it starting on Monday, if not over the weekend.

Monday is fine - I think by Wednesday we might have to look at an internal deployment. We're currently using a git link to a branch of my repo (from before I rolled back the tests).

The code changes are all coming from https://github.com/JackuB/diff-match-patch which was adjusted to better suit use embedded in a JavaScript application, as NPM developers expect, where the Google code is based on globals and standalone use. I don't have much knowledge about them other than this setup works in our application.
The Diff api change, for example, was actually a rollback - a google patch in 2018 made new Diff tuple objects, but they're non-iterable which breaks ES6 environments. So it was swapped back to a plain array.
https://github.com/JackuB/diff-match-patch/issues/14

start by automating the build process of the existing repo

I admit I have no idea what that is 😂  I have only looked seriously at the javascript folder.

this all reminds me how important it feels to get a CI job established for building the JS module. if you want to speed things up, you can work on that before I get to it. that is, start by automating the build process of the existing repo, then once that's in place, modify it so that it builds the npm package automatically.
or we could do this in one step, but only when ensuring that nothing breaks backwards compatbility.

on second thought this change of repo is a great opportunity to break from all the constraints from diff-match-patch, like Closure compiler. I forget that nobody has this official repo in their npm projects because it's never published one.
let's see if we can get a CI job setup which produces a minified build, and let's compare that output to what Closure Compiler has been producing. I'm inclined to try something like biomejs which doesn't pull in a bunch of dependencies.

I forget that nobody has this official repo in their npm projects because it's never published one.

That's the key I'm focusing on - anyone using this library on NPM is doing npm install diff-match-patch and perhaps assuming it's the same, as we did, but it's not.
https://www.npmjs.com/package/diff-match-patch

@TheSpyder In #9 I eagerly added the Symbol.iterator method so hopefully that makes this PR a bit simpler. You are welcome to incorporate that change by merge or rebase or however you want.

@dmsnell I think I've covered most of the feedback now - it's just the ESM question (whether to make it the default, whether to make it a new PR) that I'm not sure about.

@TheSpyder I'll try and get back to this in the next few days after thinking more about ESM. I'm tempted to be a bit aggressive and focus more on the future direction and letting new code accept this. Seems like most projects today can and should be able to handle an ESM package. If it's not clear, we can merge and iterate later. Thanks for your patience with me again. It's been a very busy couple months on my end and I didn't mean to let this go so long.

@dmsnell ok, what I might do in the meantime is update the testing code I pulled out of this PR and make a new PR with it. There's not really a rush on publishing this, although my team has been asking me why we're still deploying production code that depends on my personal github fork of this project 😅

It's plausible that all this can all still work with a swap to new Diff(), but I'm not entirely confident about that change.

It wasn't hard to do and seems to work, so I'm happy to go with the object.

@dmsnell in an earlier comment you mentioned perhaps the ESM change should be a separate PR. I'm happy to do that, if you decide that's the path forward, or extract it to a new PR.
I've created new branches to add types and tests, as separate PRs, once this change is approved and merged. They're working very well on my team's project.

@dmsnell now that we've brought the test changes back in, can we bring the types as well? Or should that still be a separate PR?
https://github.com/dmsnell/diff-match-patch/commit/7e93e49d258c354c09f63087e06dde6d2a3428de

One interesting thing I noticed when exploring the tests is that Diff objects behave like arrays in some ways, but are not arrays. There are a lot of test assertions that abuse this and compare tuples with diff objects, e.g. [ DIFF_EQUAL, "" ] === new Diff( DIFF_EQUAL, "" ). If we replace the array shorthand with Diff object creation, then we can replace the recursive equality check function with deepEqual.

It's a result of a change that was made years ago; the diff used to be an array, google changed it to an object. The tests haven't changed since then. For this PR, I want the absolute minimal changes to get it on NPM - perhaps log that as a new issue?

@dmsnell I think I have a github action that will run the node tests, but probably best to save that for a new PR 🤔

Yeah @TheSpyder let's suggest those CI runs in a separate PR. Bravo! Thank you for staying persistent with this.
https://www.npmjs.com/package/@dmsnell/diff-match-patch
Feel free to start using it, and let's continue making it better!

Fantastic! thank you
It will be easier for my team to use with types, I might make two PRs 🫣


 The status doesn't even open for me, and it doesn't appear on the phone.

 The status doesn't even open for me, and it doesn't appear on the phone.
Environment

WhatsApp version: 2.2334.12
WA-JS version(s): 2.24.7
Browser: Chrome <IP_ADDRESS>
OS: Linux x86_64
MultiDevice (BETA): yes

Steps to Reproduce

WPP.status.sendImageStatus(base64string)

Additional context / Screenshot

i got same error did u resolve it?


Fix opacity edge case in UsdPreviewSurface

This changelist fixes an edge case for the opacity computation in UsdPreviewSurface, making surfaces visible when their non-zero opacity is exactly equal to the opacity threshold.
This aligns the MaterialX graph for UsdPreviewSurface with its specification (https://graphics.pixar.com/usd/release/spec_usdpreviewsurface.html), which states:
"... when opacityThreshold is greater than zero, the opacity values less than the opacityThreshold will not be rendered, and the opacity values greater than or equal to the opacityThreshold will be fully visible."

Thanks to @klucknav and @spiffmon for noting this issue, and I've CC'ed them both for validation of this proposed change.


Point help button in output window to proper docs for this step

return a more intelligent error for the end user to know what to do next


Test for run with returnErrors set to true

I've added my first test.
Hopefully I did it right - I'm not sure how to test it.

Merged in 9931806


Verify Building & Running Component Demos steps

https://github.com/driftyco/ionic/blob/2.0/scripts/README.md#building--running-component-demos

Should be good


numerical (?) issues with multithreaded runs

Running the same calculation with either -t1 or -tauto is giving small differences in even the first iteration when starting from single vectors from multiple roots
 ===================================================================
     Selected CI Iteration:    1 epsilon:   0.00100000
 ===================================================================
 Build Hamiltonian matrix with dimension:    25
  0.001247 seconds (15.92 k allocations: 326.172 KiB)
  Root       Energy           S2
     1 -18.32003824   0.00000000
     2 -17.65879673   1.99998754
     3 -17.65230384   1.99988141
     4 -17.65098494   0.00011089

 ===================================================================
     Selected CI Iteration:    1 epsilon:   0.00100000
 ===================================================================
 Build Hamiltonian matrix with dimension:    25
  0.001236 seconds (15.92 k allocations: 326.172 KiB)
  Root       Energy           S2
     1 -18.32003824   0.00000000
     2 -17.65881088   2.00000000
     3 -17.65231530   2.00000000
     4 -17.65101589   0.00000000

input file attached
test_matvec.txt

This also exists for BST. The first inconsistency occurs during the matvec

It's probably an issue of the order that the sigma Tuckers are added. Maybe collect all and do 1 SVD on the super-wide matrices to find the span.


feat: Select latest version on startup + game selection

setup code style + husky for commit hooks

Cool, is this ready for review?

Cool, is this ready for review?

it is ready freddy!

There seems to be a lot of changes and commits are not really scoped (feat includes formatting etc.). I'm not sure about the husky usage as well. Seems a bit hacky + there is a lot of shellcheck warnings. I wonder if we can simplify this to only solve #2 and do nothing else. We can have separate PRs for other things.

I can definitely split up the workload into different prs.
Husky isn't a Jacky solution, it's widely known in the web dev world for running git hooks. I like to setup pre commit and pre push hooks to make sure the code is linted, styled and builds correctly.
It's only Jacky because I setup some custom bash commands which look odd.

I think splitting commits would be good. It's a little hard to find the latest version selection change in all the formatting changes.
About Husky, I'd be open to it conceptually, but I'm a little confused. What's husky doing exactly?
Doesn't git have a way to run bash scripts on commit? How is it different than just using normal git hooks.?

I think splitting commits would be good. It's a little hard to find the latest version selection change in all the formatting changes.

Yup, I agree.


increase the ephemeral disk on the vSphere compilation vm

A compilation VM with only 3GB of disk is insufficiently small for the Concourse 5.0 bosh release.
I imagine there are probably other bosh releases that fail to compile due to insufficient disk space.

Hey @markstokan thanks for the PR. We're inclined to keep using default disk type, and instead increase the default disk size to be larger. Would you mind updating the PR with that change?

squashed.

This is a significant change to a common VM type. Deployment footprints relying on this now have a 10x increase in disk requirements which can be particularly valuable in vSphere environments.
For that reason, I don't really like this change. Can we instead solve the original problem by changing the compilation VM type to use the existing large type which already has a 30GB disk? This would significantly reduce the impact to vSphere environments and avoid changing behavior that we haven't otherwise heard concerns about.

My original pull request did that, Danny.  The feedback from Morgan was your team preferred to increase the disk size of the "default" vm instead of switch vm_types.
I'll let your team decide internally how you want to implement this change.
FWIW... the vsphere bosh cpi docs at: https://bosh.io/docs/vsphere-cpi/ suggest using a "large" vm
- name: large
  cloud_properties:
    cpu: 2
    ram: 4096
    disk: 30_240

We'll chat more; sorry for the confusion.

Hey Mark, sorry for the back and forth. We're going to keep the change as is now, and if we get feedback in the future we can adjust appropriately. Thanks for the PR!


br: show the details of the error occurred when get the azure ad token

What is changed and how it works?

Issue Number: Close #15384
What's Changed:
output the debug information of the error to show the details

Related changes

PR to update pingcap/docs/pingcap/docs-cn:
Need to cherry-pick to the release branch
v6.5, v.7.1

Check List
Tests

Manual test (add detailed scripts or steps below)
see the issue

Release note
None

/merge


Support Texture widget in GLFW embedding

See google/flutter-desktop-embedding#107 for discussion

@stuartmorgan I tried creating a Texture patch for windows/linux on the https://github.com/cloudwebrtc/flutter-desktop-embedding/commit/8a7c6ab556c4f60626051bee61d5dfbe680ca002 branch,  and after testing, I will try to create a PR to the flutter/engine.

I have implemented Texture for GLFW (windows) rendering, and there are some minor issues, but it can be solved very quickly.

@cloudwebrtc any progress on this issue? What branch did you fix the glfw texture widget rendering in?

@chichid The function implementation has been completed and the PR is under review.
Please refer to the link below:
https://github.com/flutter/engine/pull/9822
https://github.com/flutter/engine/pull/12265
https://github.com/flutter/flutter/pull/36818

Do you still need Texture on GLFW, as we have turn into Win32 on Windows and GTK on Linux?

It is possible that the specific internal clients that still rely on the GLFW embedding will need this functionality at some point. That's not currently the case, which is why this is P6.


changed line 16, story #4: project-tile to project-title (correct spe…

…lling to pass the test)

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.


Use gb build tool.

This makes it easier to build Go projects and maintaining dependencies without having the need for $GOPATH, etc.

You borked the PR. Way to go, Simao! :D


Whenever I close the webview and reopen it, a flashing white interface appears

Column(
children: [
Container(height: 30, color: Colors.yellow, child: ElevatedButton(onPressed: (){
setState(() {
showBrowser = !showBrowser;
});
}, child: Container(color: Colors.blue)),),
Expanded(child: showBrowser ? Container(color: Colors.red,):ExampleBrowser()),
],
)
I use this code to add a button to control the display and hiding of webview.

https://github.com/user-attachments/assets/05649cb5-a762-4c9a-877e-3569aa149a46

Is there a good solution?


log-style API proposal

I'm excited people are working on a metrics library for rust! I've been wanting one for a while. Your reddit post said you were okay with big API design ideas, so here are some i've been noodling on :)
The design I was contemplating is something like log, where there's a tiny facade crate with simple macros that library authors can use freely, that calls into a global trait object for functionality; binaries can then install an implementation that does what they want.
E.g., library code can do something like:
use metrics::gauge;

gauge!(request_time, 123);

(Or, if we want to get fancy, you could also more metadata, like prometheus-style tags and opencensus-style units:)
gauge!(request_time, 123ns, endpoint="/app/thing", method=http::POST);

You could also have other macros to record counters, histograms, time blocks of code, etc. But it's all just simple macros.
Then, users can install a metrics implementation:
fn main() {
   // note: NOT the core metrics crate!
   magic_metrics_library::setup()
     .with_recorder(PrometheusRecorder::new())
     .with_exporter(HttpExporter::new())
     .filter("hyper") // don't include hyper metrics...
     .install();

   start_http_server();
}

And boom, they're done! That's the whole user facing API. Users don't need to know anything more about the internal details of the library. This is especially nice because it means library authors can just add metrics, fire-and-forget style; the core crate is so small that it adds very little compile-time cost, and also practically no runtime cost. (log without a logger installed has a 1ns overhead per-call, by my measurements.) As a result, when a user installs a metric exporter, they'll hopefully have a load of metrics available for free; assuming the facade crate gains adoption.
Now, the implementation. Basically, the core metrics crate contains a core Metrics trait that allows metrics to be recorded -- the API surface looks similar to the Recorder trait, but its responsibilities are broader; it's responsible for the whole metric recording process. It also contains a global, atomically initialized static METRICS: Box<dyn Metrics> trait object. Then, each gauge!, counter!, or histogram! call simply calls a method on this trait object. (You can look at log to see how this works.)
Note that we don't even have SnapshotProvider / Exporter / etc here! Those are super useful, but they can be moved to a crate for backend implementors -- we don't want their compile time cost in the facade crate. (Note: I've been calling the facade crate metrics in the style of log, but it could be metrics_core instead.)
So, that's the design sketch. Thoughts? I know this is pretty significantly different from the current design of the crate, but no code would actually need to be deleted -- the current code would only need a thin shim to comply with this API. This would also allow users more flexibility -- e.g. library authors don't need to be worried about dragging crossbeam in as a dependency, since the facade crate wouldn't have any dependencies; users pay for what they need.

Notes on optimization: it might seem like this design is incompatible with the high-performance crossbeam-based design this crate currently uses. Doesn't that require local sinks for each thread? Sure, we can do that, with... thread-locals:
thread_local! {
   static SINK: Sink = GLOBAL_SINK.clone();
}
impl Metrics for SinkCreator {
   fn record_gauge(data: GaugeData) {
      SINK.with(|sink| sink.send(data))
   }
}

Another fun optimization is allowing the global Metrics implementation to pre-process callsites. Since most of the information about a single gauge! invocation won't change -- the metric type, unchanging tags, etc. -- you can allow memoizations like so:
pub struct CallsiteToken(usize);

// data about a callsite that doesn't change.
struct CallsiteMetadata {
    metric_type: MetricType,
    source_module: &str,
    tags: &[Tag],
    // ... other stuff ...
}

trait Metrics {
   fn init_callsite(metadata: &'static CallsiteMetadata) -> CallsiteToken;
   fn record(token: CallsiteToken, value: f64);
}

Now, associate each callsite with a static, atomically initialized CallsiteToken; that token will be initialized with the callsite's metadata, and then passed into record whenever that callsite is hit in the future. Since the token's just an int, and the implementation controls its value, the implementation can use it to directly index into tables of sample buffers, etc. This means you don't need to hash recordings and things at runtime :)

So, I'll have to take a deeper look at all of this to make sure I'm grokking your proposal properly, but first thoughts:
I love the idea of providing a path for "simplest possible metrics configuration" based on macros and a global receiver.  At some point, you basically want/need a global Receiver anyways to be able to grab a new sink from a given thread, and it helps make the ownership of the Receiver (since it needs to stick around for the export stuff) simpler.  Just make it a lazy_static, done.
With that said, a lot of the spirit of your proposal, IMO, aligns heavily with what tokio-trace is looking to do, which is nearly identical from the perspective of a facade crate that, as more people use it in their crates, end users get the instrumentation benefit for free*
And with that said, the crux of why we created metrics-core with those foundational traits was the idea of being able to create a tokio-trace subscriber -- say, tokio-trace-metrics, that would take something that fit the "record some metrics" traits and be able to turn spans into metrics for us, for free*.  We'd be slightly abusing the distributed tracing-orientedness to derive these structured metrics for end users with little to no input, but it would get us a lot of timing-based things for free.  Since tokio-trace also supports free-form event! calls -- basically identical to log! and spitting out a single entry -- we figured we could also jam counters/gauges in there as well with some field name matching.
On top of that, the intention to support filtering of given metrics/spans, etc, is already a working idea for tokio-trace.  And, since it's likely to come up as a question for a long time: tokio-trace does not need tokio to run at all... it's only related in name, and can be used in any application, so it still aligns with metrics on that front.
With alllll of that said, I'm still intrigued by metrics itself being able to provide this stuff for people who may not want tokio-trace or aren't yet tied into that ecosystem.  It's totally possible we may decide we're not OK with having tokio-trace-specific macros and instead want metrics-specific macros, etc... so I'm gonna leave this open to ruminate on. :)

Oh, I hadn't looked at tokio-trace in a long time, that makes sense! (they should really change their name to just, like, "trace", lol.)
I do think it makes sense to provide a metrics facade crate, even if that crate is implemented using tokio-trace. There are plenty of metrics that aren't solely time- or count-based, ideally there'd be a clean api for using those.

I think the facade is a great idea as a standalone, for tokio-trace I already have a working subscriber for internal use at work. My hope is to open source this soonish.

Gonna close this ticket as I just merged #20 🎉
There should probably be a follow-up issue to discuss static callsite metadata/tokenization, as that involves some trickier synchronization and needs some thought.


[mtl] Buffer views, combined image-samplers

Fixes #1935
PR checklist:

[x] make succeeds (on *nix)
[x] make reftests succeeds
[x] tested examples with the following backends:

Concerns are addressed now. Thanks for the review!
bors r=grovesNL


error after using npx create-payload-app<EMAIL_ADDRESS>couldn't be built successfully

Link to reproduction
No response
Describe the Bug
When I run yarn after creating a project using create-payload-app, I get a build error:
~/sample-payload is 📦 v1.0.0 via  v18.17.1 took 3s
❯ ~/sample-payload is 📦 v1.0.0 via  v18.17.1 took 6m4s
❯ yarn
➤ YN0000: · Yarn 4.0.2
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed in 0s 383ms
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed in 0s 881ms
➤ YN0000: ┌ Link step
➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
➤ YN0007: │ sharp@npm:0.32.6 must be built because it never has been before or the last one failed
➤ YN0009: │ sharp@npm:0.32.6 couldn't be built successfully (exit code 1, logs can be found here: /tmp/xfs-e8095929/build.log)
➤ YN0000: └ Completed in 0s 510ms
➤ YN0000: · Failed with errors in 1s 864ms

To Reproduce

Run npx create-payload-app and follow the instructions
Run yarn to install dependencies

Payload Version
2.0.0
Adapters and Plugins
db-mongodb, bundler-webpack, plugin-cloud, richtext-slate

This step also fails when I try to run the same in an alpine docker container.
Here's the build log:
# This file contains the result of Yarn building a package (sharp@npm:0.32.6)
# Script name: install

node:internal/modules/cjs/loader:1144
  const err = new Error(message);
              ^

Error: Cannot find module './process'
Require stack:
- /var/home/aadil/.yarn/berry/cache/detect-libc-npm-2.0.2-03afa59137-10c0.zip/node_modules/detect-libc/lib/detect-libc.js
- /var/home/aadil/sample-payload/.yarn/unplugged/sharp-npm-0.32.6-6b3822c437/node_modules/sharp/install/libvips.js
Require stack:
- /var/home/aadil/.yarn/berry/cache/detect-libc-npm-2.0.2-03afa59137-10c0.zip/node_modules/detect-libc/lib/detect-libc.js
- /var/home/aadil/sample-payload/.yarn/unplugged/sharp-npm-0.32.6-6b3822c437/node_modules/sharp/install/libvips.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1144:15)
    at require$$0.Module._resolveFilename (/var/home/aadil/sample-payload/.pnp.cjs:20043:54)
    at Module._load (node:internal/modules/cjs/loader:985:27)
    at require$$0.Module._load (/var/home/aadil/sample-payload/.pnp.cjs:19957:31)
    at Module.require (node:internal/modules/cjs/loader:1235:19)
    at require (node:internal/modules/helpers:176:18)
    at Object.<anonymous> (/var/home/aadil/.yarn/berry/cache/detect-libc-npm-2.0.2-03afa59137-10c0.zip/node_modules/detect-libc/lib/detect-libc.js:7:32)
    at Module._compile (node:internal/modules/cjs/loader:1376:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
    at require$$0.Module._extensions..js (/var/home/aadil/sample-payload/.pnp.cjs:20109:33) {
  code: 'MODULE_NOT_FOUND'
}

Node.js v20.11.0
node:internal/modules/cjs/loader:1144
  const err = new Error(message);
              ^

Error: Cannot find module './process'
Require stack:
- /var/home/aadil/.yarn/berry/cache/detect-libc-npm-2.0.2-03afa59137-10c0.zip/node_modules/detect-libc/lib/detect-libc.js
- /var/home/aadil/sample-payload/.yarn/unplugged/sharp-npm-0.32.6-6b3822c437/node_modules/sharp/lib/platform.js
- /var/home/aadil/sample-payload/.yarn/unplugged/sharp-npm-0.32.6-6b3822c437/node_modules/sharp/lib/libvips.js
- /var/home/aadil/sample-payload/.yarn/unplugged/sharp-npm-0.32.6-6b3822c437/node_modules/sharp/install/can-compile.js
Require stack:
- /var/home/aadil/.yarn/berry/cache/detect-libc-npm-2.0.2-03afa59137-10c0.zip/node_modules/detect-libc/lib/detect-libc.js
- /var/home/aadil/sample-payload/.yarn/unplugged/sharp-npm-0.32.6-6b3822c437/node_modules/sharp/lib/platform.js
- /var/home/aadil/sample-payload/.yarn/unplugged/sharp-npm-0.32.6-6b3822c437/node_modules/sharp/lib/libvips.js
- /var/home/aadil/sample-payload/.yarn/unplugged/sharp-npm-0.32.6-6b3822c437/node_modules/sharp/install/can-compile.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1144:15)
    at require$$0.Module._resolveFilename (/var/home/aadil/sample-payload/.pnp.cjs:20043:54)
    at Module._load (node:internal/modules/cjs/loader:985:27)
    at require$$0.Module._load (/var/home/aadil/sample-payload/.pnp.cjs:19957:31)
    at Module.require (node:internal/modules/cjs/loader:1235:19)
    at require (node:internal/modules/helpers:176:18)
    at Object.<anonymous> (/var/home/aadil/.yarn/berry/cache/detect-libc-npm-2.0.2-03afa59137-10c0.zip/node_modules/detect-libc/lib/detect-libc.js:7:32)
    at Module._compile (node:internal/modules/cjs/loader:1376:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
    at require$$0.Module._extensions..js (/var/home/aadil/sample-payload/.pnp.cjs:20109:33) {
  code: 'MODULE_NOT_FOUND'
}

Node.js v20.11.0

This may be related : https://github.com/lovell/sharp/issues/3833

This error also occurs when running npx create-payload-app@latest instead of npx-create-payload:
Log:
❯ npx create-payload-app@latest
Need to install the following packages:
<EMAIL_ADDRESS>Ok to proceed? (y) y

  Welcome to Payload. Let's create a project!

✔ Project name? … sample-payload
✔ Choose project template › blank
✔ Select a database › MongoDB
✔ Enter MongoDB connection string … mongodb://<IP_ADDRESS>/sample-payload

  Creating project in /var/home/aadil/sample-payload

⠧ Installing dependencies...{
  err: Error: Command failed with exit code 1: yarn
  ➤ YN0000: · Yarn 4.0.2
  ➤ YN0000: ┌ Resolution step
  ➤ YN0085: │ + @payloadcms/bundler-webpack@npm:1.0.6, @payloadcms/db-mongodb@npm:1.3.2, @payloadcms/plugin-cloud@npm:3.0.0, @payloadcms/richtext-slate@npm:1.3.1, and 1089 more.
  ➤ YN0000: └ Completed in 2s 412ms
  ➤ YN0000: ┌ Fetch step
  ➤ YN0000: └ Completed in 0s 738ms
  ➤ YN0000: ┌ Link step
  ➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
  ➤ YN0007: │ es5-ext@npm:0.10.62 must be built because it never has been before or the last one failed
  ➤ YN0007: │ sharp@npm:0.32.6 must be built because it never has been before or the last one failed
  ➤ YN0007: │ @swc/core@npm:1.3.76 [ed3e5] must be built because it never has been before or the last one failed
  ➤ YN0009: │ sharp@npm:0.32.6 couldn't be built successfully (exit code 1, logs can be found here: /tmp/xfs-192d0d46/build.log)
  ➤ YN0000: └ Completed in 1s 781ms
  ➤ YN0000: · Failed with errors in 5s 100ms
      at makeError (/var/home/aadil/.npm/_npx/a78262c2ecc815d9/node_modules/execa/lib/error.js:60:11)
      at handlePromise (/var/home/aadil/.npm/_npx/a78262c2ecc815d9/node_modules/execa/index.js:118:26)
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
      at async installDeps (/var/home/aadil/.npm/_npx/a78262c2ecc815d9/node_modules/create-payload-app/dist/lib/create-project.js:50:9)
      at async createProject (/var/home/aadil/.npm/_npx/a78262c2ecc815d9/node_modules/create-payload-app/dist/lib/create-project.js:84:20)
      at async Main.init (/var/home/aadil/.npm/_npx/a78262c2ecc815d9/node_modules/create-payload-app/dist/main.js:79:21)
      at async main (/var/home/aadil/.npm/_npx/a78262c2ecc815d9/node_modules/create-payload-app/dist/index.js:8:5) {
    shortMessage: 'Command failed with exit code 1: yarn',
    command: 'yarn',
    escapedCommand: 'yarn',
    exitCode: 1,
    signal: undefined,
    signalDescription: undefined,
    stdout: '➤ YN0000: · Yarn 4.0.2\n' +
      '➤ YN0000: ┌ Resolution step\n' +
      '➤ YN0085: │ + @payloadcms/bundler-webpack@npm:1.0.6, @payloadcms/db-mongodb@npm:1.3.2, @payloadcms/plugin-cloud@npm:3.0.0, @payloadcms/richtext-slate@npm:1.3.1, and 1089 more.\n' +
      '➤ YN0000: └ Completed in 2s 412ms\n' +
      '➤ YN0000: ┌ Fetch step\n' +
      '➤ YN0000: └ Completed in 0s 738ms\n' +
      '➤ YN0000: ┌ Link step\n' +
      '➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental\n' +
      '➤ YN0007: │ es5-ext@npm:0.10.62 must be built because it never has been before or the last one failed\n' +
      '➤ YN0007: │ sharp@npm:0.32.6 must be built because it never has been before or the last one failed\n' +
      '➤ YN0007: │ @swc/core@npm:1.3.76 [ed3e5] must be built because it never has been before or the last one failed\n' +
      "➤ YN0009: │ sharp@npm:0.32.6 couldn't be built successfully (exit code 1, logs can be found here: /tmp/xfs-192d0d46/build.log)\n" +
      '➤ YN0000: └ Completed in 1s 781ms\n' +
      '➤ YN0000: · Failed with errors in 5s 100ms',
    stderr: '',
    failed: true,
    timedOut: false,
    isCanceled: false,
    killed: false
  }
}
✖ Error installing dependencies
✔ .env file created
✔ Payload project successfully created

  ★ Launch Application:

    - cd ./sample-payload
    - yarn dev or follow directions in README.md

  ★ Documentation:

    - Getting Started
    - Configuration

I have checked it as you said but didnt get any error or issue on mine. I am on windows and using yarn 1.8, maybe its related with your yarn version.
>npx create-payload-app@latest
Need to install the following packages:
<EMAIL_ADDRESS>Ok to proceed? (y) y

  Welcome to Payload. Let's create a project!

√ Project name? ... test
√ Choose project template » blank
√ Select a database » MongoDB
√ Enter MongoDB connection string ... mongodb://<IP_ADDRESS>/test

  Creating project in .\test

√ Dependencies installed
√ .env file created
√ Payload project successfully created

  * Launch Application:

    - cd ./test
    - yarn dev

I had the same error when trying to build my payload app with pnpm on Ubuntu.
As per @aadilayub post, adding the following to package.json fixed the bug for me.
  "overrides": {
    "payload@latest": {
      "sharp": "^0.33.2"
    }
  },

@craigrdaniels this worked, thank you!
Also for the Docker error, shifting to node:21-bookworm instead of node:18-alpine as the base image got rid of the error

Ran into this error again today while creating a new payload app (both using create-payload-app and create-payload-app@latest). Unfortunately, @craigrdaniels' suggestion did not work this time.
I could try with pnpm, but I think it should work with yarn by default, since that's the package manager suggested in the README.

Ran into this error again today while creating a new payload app (both using create-payload-app and create-payload-app@latest). Unfortunately, @craigrdaniels' suggestion did not work this time.
I could try with pnpm, but I think it should work with yarn by default, since that's the package manager suggested in the README.

Try this instead, I used an incorrect syntax before which I'm now not sure how it worked in my other project.
This got rid of the sharp errors for me. I tested this on a brand new create-payload-app demo page. And this build fine on docker node:20-alpine using pnpm.
Looks like the syntax is the same for yarn.
  "resolutions": {
    "sharp": "^0.33.2"
  },


cfops backups cannot be backedup to a s3 compatible blob store

If I am using cfops with s3 where do I configure the URL of my s3 host ?
Does cfops assume amazon AWS s3 ?
cfops documentation claims that You can use an s3 compatible blobstore for backups
How is this achieved.
All the documentation and reading the  code only points to support for AWS S3
Can someone shed light on the non AWS S3 compatibility of cfops s3 backups

From @xchapter7x
So the missing piece of the puzzle is setting this env variable
export S3_DOMAIN=<some_compatible_s3_store_url>


storage/oasis: Cache init failure is not longer fatal

When the node RPC cache (backed by a pogreb db) fails to initialize, our current code prevents the entire analyzer from starting. This PR makes it so that a failure to initialize the cache merely reports a warning, and continues without the cache.
Testing: Manual.

Ran the analyzer with a functioning cache; works.
Ran the analyzer with cache_dir: /does-not-exist, produced a warning and continued as expected.

Aborting this PR. As discussed internally, I'd prefer to keep cache failure handling explicit (= one has to disable cache in the config) so we are more aware of caching issues. The team agrees.
Mitigations to the root cause will follow in future PRs:
The problematic situation is when
a) the pogreb store needs reindexing and
b) the sapphire or emerald nodes are unavailable.
Because of (b), nexus initialization keeps failing in a fatal way. (Nexus is lazy about connecting to the node, but not for the runtimes because it uses the SDK in addition to the raw RPC connection.) But by the time that fatal error occurs, pogreb has already started the recovery process, including .bac creation. Then k8s keeps restarting nexus. At this point, if the runtime node became available, all would be good.But it typically stays unavailable or a while, so the .bac files pile up, until eventually the pogreb recovery fails (because it cannot create backups) and nexus terminates before it even tries to connect to the runtime node. At that point, every restart will fail, so  when the runtime node eventually comes back up, nexus never learns about it.
We should ideally stop using the SDK, or change it so it can connect lazily. We should also pre-clean-up the .bac files to prevent pogreb from failing just due to filename buildup.


Blank map with Maxar Imagery Standard (Beta) layer

Outdated API id?

Other layers for the same region appear to be working alright:

I think we may need to re-pull from the imagery database. @jschwarz2030 do you think that would solve this problem?

Maxar Standard is no longer in service and we are switching to Maxar Premium.  After changing our configuration, it appears to be working in staging and production.  This should be fully resolved.  Thanks for reporting!


Timeout after particular command sequence

Use the below steps to reproduce the timeout (hopefully, if it is reliably reproducible).
(1) Start the default Garnet server, ideally with --logger-level Debug
(2) Run the below code (or use the ready attached console app project).
It works fine on the first run and we can see complete session cycles logged:
10::47::21 dbug: GarnetServer[0] [:3278] Accepted TCP connection from <IP_ADDRESS>:50991
10::47::21 dbug: Session[0] [:3278] [<IP_ADDRESS>:50992] [009A2F17] Starting RespServerSession
10::47::21 dbug: Session[0] [:3278] [<IP_ADDRESS>:50991] [02B89EAA] Disposing RespServerSession

(3) Run the code again. In my case it always times out on the second and next runs.
Incomplete session cycles during waiting suggest that waiting happens on the server:
10::47::28 dbug: GarnetServer[0] [:3278] Accepted TCP connection from <IP_ADDRESS>:50995
10::47::28 dbug: Session[0] [:3278] [<IP_ADDRESS>:50995] [02A42D56] Starting RespServerSession

The client code (or use the ready attached console app project):
GarnetIssue1.zip
using StackExchange.Redis;

using var redis = ConnectionMultiplexer.Connect("localhost:3278");
var db = redis.GetDatabase();

var key = "test:issue";

db.StringSet(key, "a");

db.KeyDelete(key);
db.SetAdd(key, "b");

db.KeyDelete(key);
db.ListRightPush(key, "c");

Environment:

Garnet 1.0.4 (I think 1.0.3 has the same issue).
StackExchange.Redis 2.7.33
Windows 11

By default, if the --bind is not specified Garnet will use the LAN IP. You can start the server --logger-level=Trace and see the view the server IP address as in the below example. I think that is the issue which results in SERedis not connecting.

I am not sure about the answer (was it an advice?). Is this the configuration issue? What should I specify as --bind?

I think that is the issue which results in SERedis not connecting.

I am not sure what this means, too. SERedis is connecting and works as such. Here are some tests, all pass with "default Garnet"
https://github.com/nightroman/FarNet.Redis/tree/main/tests
But the particular sequence of "simple" commands (provided) causes timeouts.

It's alright I think there was a confusion with the IP you provided and was not able to repro your issue.
The issue was that DEL had bug and was not working properly. Created a PR to fix this issue https://github.com/microsoft/garnet/pull/284.
Run your example and it seems to work fine.

@vazois Thank you, I cannot reproduce this issue with the latest. Closing and looking forward to Microsoft.Garnet 1.0.6 at NuGet


HTTP client question

Is there a regular HTTP request client that does not require complex lmdeploy package installation and gRPC calls, nor does it need streaming transmission, returning all answer results in a single response.

like openai RESTful APIs?

像 openai RESTful API 一样？

Yes, this kind of regular HTTP client would be very convenient for use and integration. Also, as a suggestion, the preprocess and postprocess models can be implemented with the Triton framework ensemble mode, so that all steps can be completed with just one request to the interface. Just like the GPT example in the FasterTransformer project.
https://github.com/triton-inference-server/fastertransformer_backend/tree/main/all_models/gpt

We are working on it now.

Hi I opened the --allow-http=1 option before running the service_docker_up.sh, but "curl -v  http://<IP_ADDRESS>:8000/v2/models/llama2" always return "unknown model"（grpc interface works without problem), does it because restful api is not supported now? thank you.

Hi I opened the --allow-http=1 option before running the service_docker_up.sh, but "curl -v http://<IP_ADDRESS>:8000/v2/models/llama2" always return "unknown model"（grpc interface works well), does it because restful api is not supported now? thank you.

The restful APIs were added. But they are not through triton server. For more details please refer to https://github.com/InternLM/lmdeploy/blob/main/docs/en/restful_api.md


range check gate - relocate lookups to MSB

Matthew has suggested a strategy to allow a configurable lookup range is to move the lookups to the MSB so that bytes in these cells can be constrained to zero.  For example, to get a 64 bit range-check we can simply constraint the top 24 bits of the first lookup to zero.

Tested optimization over 20 runs.  It didn't make any improvement.
vanilla: 35.95s
optimization: 36.57s


Update readme.md

Updating Endpoints in Readme.md File
Closes #1

@cyberdad68 Thank you for your contributions. Really appreciate it.
If you have any doubts regarding your hacktoberfest related stuff, just ask me.
Thanks man.

@alanJames00 Could you please add Hacktoberfest Accepted Label on this Repo.

Added 👍.
BTW, did you receive any email from hacktoberfest saying that your PR is under review ??

Added 👍.
BTW, did you receive any email from hacktoberfest saying that your PR is under review ??

Yes,it is under review.


[FEATURE] Improve Doctest framework to sort result rows consistently

Is your feature request related to a problem?
Currently, Doctest module depends on backend and use the result set for comparison directly. Specifically, whenever there is filtering operation (SQL WHERE clause or PPL where command), sorting by _doc field is added automatically. This is supposed to be special case and moved to client side.
What solution would you like?
Sort the result rows in consistent way before formatting and comparison. This is similar as what our comparison test framework does. This approach may be favored over the alternative as follows.
What alternatives have you considered?

Add ORDER BY clause or sort command to each SQL/PPL query to make sure consistent order in result set. This may complicate the sample query and thus make it unclear to users.
Remove the default sorting and fix all doctest manually. However, the result maybe still not deterministic and the test may fail if the result rows is returned in different order.

Do you have any additional context?
Code: https://github.com/opensearch-project/sql/blob/2.x/opensearch/src/main/java/org/opensearch/sql/opensearch/request/OpenSearchRequestBuilder.java#L138
  public void pushDown(QueryBuilder query) {
    ...
    if (sourceBuilder.sorts() == null) {
      sourceBuilder.sort(DOC_FIELD_NAME, ASC); // Make sure consistent order
    }
  }

Doctest depends on the logic above:
    ppl_cmd.process('source=accounts | where account_number=1 or gender="F" | fields account_number, gender')Expected:
    fetched rows / total rows = 2/2
    +------------------+----------+
    | account_number   | gender   |
    |------------------+----------|
    | 1                | M        |
    | 13               | F        |
    +------------------+----------+
Got:
    fetched rows / total rows = 2/2
    +------------------+----------+
    | account_number   | gender   |
    |------------------+----------|
    | 13               | F        |
    | 1                | M        |
    +------------------+----------+

Commit related: https://github.com/opendistro-for-elasticsearch/sql/pull/671/files#diff-63bd53f53ffecab84aea9982f55e14def091fd8cc7f5cab1fd45de9eba2fedda


Update value proposition

closes #52

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


Allow using external stackdriver credentials

Currently, the only way to provide credentials for Stackdriver
exporter is by file inside application's jar resources. This
means credentials file needs to baked into application jar.
This solution uses credentials pointed by GOOGLE_APPLICATION_CREDENTIALS env
when credentialsFile if not specified in application.conf.
Related: #112

[warn] /home/travis/build/census-ecosystem/opencensus-scala/core/src/main/scala/io/opencensus/scala/trace/exporters/Stackdriver.scala isn't formatted properly!
[error] 1 files must be formatted

Just compile once with sbt compile and it should autoformat all the files.


Thermocycler: firmware: control 3 separate peltier drivers with PID loops (PID fine tuning)

overview
New h/w version has 3 separate drivers controlling individual peltiers. We need to finalize the control of all 3 peltiers in a way that gets us the best uniformity of temperature throughout the plate:
by having either varying PID constants for each of the PID loops or keeping them the same
We also need to fine tune the PID values whichever method we choose, but in a way the tuning results would determine which method works best. So this is going to be one giant ticket involving very little firmware changes but a lot of experimentation. I will be pairing with @andy-g-calderon for this
current behavior
Currently we have a separate PID loop for each peltier but all the loops share the same Kp, Ki, Kd. Temperature uniformity and stability is within our TC specifications but the ramping is too slow.
Checklist

[x] Determine the optimum PID values for a < +-0.2 degC temperature diff for stable temp (during transition from ramp to stable)
[x] Observe ramp down pattern and determine if separate PID values need to be used while ramping down
[x] Increase ramping rate ( Full PWM for ramp up/down or PID optimization. Need to decide)
[ ] Record temperature change curves for plate vs wells

The PID constants needed to be changed quite a few times since PID compute has been dependent on loop duration until now. That variability with loop time will change with #3610, following which this ticket will be revisited for one last time.


Cannot read property 'open' of undefined

Cannot read property 'open' of undefined

@vknaveenkumar thanks for reporting this. Could you provide some more detail and perhaps a code sample?

Also, please take a look at #50 and #54 and see if any of those details assist you.

i cant get it. can u please help me in solving this . At what time would u come ? (IndianStandardTime)

@vknaveenkumar I'm sorry, but without more detail I can't be of much help.

Yes, the example from the readme should suffice:
Opening and closing the modal from a parent component
import { Component, ViewChild } from '@angular/core';
import { MODAL_DIRECTIVES, ModalComponent } from 'ng2-bs3-modal/ng2-bs3-modal';

@Component({
    selector: 'parent-component',
    directives: [MODAL_DIRECTIVES],
    template: `
        <modal #myModal>
            ...
        </modal>
    `
})
export class ParentComponent {
    @ViewChild('myModal')
    modal: ModalComponent;

    close() {
        this.modal.close();
    }

    open() {
        this.modal.open();
    }
}

Also, take a look at the working demo code: https://github.com/dougludlow/ng2-bs3-modal/tree/master/demo

@dougludlow The above example you've given is not working. I am unable to import
{ MODAL_DIRECTIVES } from 'ng2-bs3-modal/ng2-bs3-modal';

What is the problem here. I've also looked at the demo example you've given but it doesn't give any example like we need & you've stated above. Please help!

@saurav12 that example is old/outdated, please refer to the example in the readme:                     https://github.com/dougludlow/ng2-bs3-modal#opening-and-closing-the-modal-from-a-parent-component
If you are getting "Cannot read property 'open' of undefined" that is because you haven't loaded bootstrap properly. ng3-bs3-modal relies on bootstrap's javascript in order to work.


Global Registry - admin password is not upgraded after re-enable Global Registry

Bug on Rancher: master
(All passwords here are random and for demonstration )
Steps:

add EBS storage class

enable GR for the first time, set admin password: NzfQ1Dd5lrLdTj27

log in Harbor as admin user PASS

docker login as admin user PASS

open Harbor page to sign up a new account: testuser1 Abcd12345

log in Harbor as testuser1 PASS

docker login as testuser1  PASS

disable GR

wait for app and workloads being deleted

re-enable GR with the same PV but a NEW admin password: 1Lo8VepiV72nq691

log in Harbor as admin user FAILED - password error BUT old password works

docker login as newuser1  FAILED - password error BUT old password works

log in Harbor as testuser1 PASS

docker login as testuser1  PASS

Regard it as expected.
This configuration is used on initialization.

harbor_admin_password: The administrator's initial password. This password only takes effect for the first time Harbor launches. After that, this setting is ignored and the administrator's password should be set in the Portal. Note that the default username/password are admin/Harbor12345 .
https://github.com/goharbor/harbor/blob/608d7d5e78df8435b15dbfab8911e72397cd4d85/docs/installation_guide.md#required-parameters

When re-enabling using the same PV, the old password that persists in the database will be used.

When users choose existing PVC, we have no idea if the data exists or not.
I think we can add a description for the field about this.

@gitlawr  Thanks for the explanation, we definitely should notify users about this.
Could you confirm the following two cases are expected?

If re-enable the global registry using the existing PVC, the admin password will be the old one

If re-enable the global registry using new PVC, the admin password will be the new one

Is there no way we can handle this better? A description is nice so user is at least aware, but if we don't have a means to update password on existing PVC can't we flag this somewhere so when we re-enable with same PVC we do not ask for harbor admin password (ui somehow knows)? (and perhaps mention it's the same password as originally set) or something like that

@jiaqiluo @davidnuzik The expected cases are:

If re-enable the global registry using new PVC, the admin password will be the new one
If re-enable the global registry using the existing PVC, and there is NO initialized data in the PV, the admin password will be the new one
If re-enable the global registry using the existing PVC, and there is initialized data in the PV, the admin password will be the old one

And for case 2&3, it is hard to know if there is initialized data before enabling from our side.

Yes, we know that. So we decided to just add a warning in admin password field

the bug fix is validated on Rancher: master with the latest version of the system-library chart
Now the UI shows the warning when re-enabling the global registry


Is there going to have any Varnish support in this docker setup?

This is just the base image to run Magento.
If you want to run Varnish you should setup a second container that proxies traffic to this one. Running Varnish in the same container as Apache is bad practice and not recommended.
How you set up your environment is entirely up to you.


Undefined method `config'

Hi guys,
I'm running into an error when trying to deploy. I'm using version 3.5.0
.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/slackistrano-2.0.1/lib/slackistrano/capistrano.rb:73:in block in post': undefined method config' for #<Capistrano::Configuration:0x007f9454232ec8> (NoMethodError)
Not sure where to look. Please maybe just point me to what this could be caused by. Thanks!

Seems to be a problem in slackistrano, a 3rd party addon. Suggest you open an issue at https://github.com/phallstrom/slackistrano

Please make sure you are using a plugin designed for Capistrano 2.

sorry yes was an old slackistrano plugin. thank you!


Snippet generation infrastructure

The current devx API is able to generate snippets from an OData context today.
Because we're moving to OpenAPI, this is going to create differences (differences in interpreting OData conventions).
TODO:

[ ] Move the ISnippetsGenerator into a new common lib project
[ ] Create a new project for OpenAPI logic
[ ] Add unit tests for that project
[ ] Add a "logic" parameter to the GraphExplorerSnippets controller so snippets of both generations can co-live
[ ] Implement generation logic for one language (TypeScript?)
[ ] Update the generation app to accept a logic argument and switch between the generators

Related #383, #384, #385, #386, #387, #388, #389
AB#10845

comment from @ddyett offline: do dotnet first so we can have a raptor story


[bzip2] build failure

Host Environment

OS: Windows 10 (using the new terminal)
Compiler: revision

To Reproduce
Steps to reproduce the behavior:
./vcpkg install 7zip bzip2
or
./vcpkg update
after doing git pull in the vcpkg directory
Failure logs
Starting package 2/6: bzip2:x64-windows
Building package bzip2[core]:x64-windows...
Could not locate cached archive: C:\Users\spej\AppData\Local\vcpkg\archives\99\991469afebbef113381a85da8c41e5e2e3ce75ea.zip
-- Using cached C:/program files/vcpkg/downloads/bzip2-1.0.6.tar.gz
-- Extracting source C:/program files/vcpkg/downloads/bzip2-1.0.6.tar.gz
-- Applying patch fix-import-export-macros.patch
-- Using source at C:/program files/vcpkg/buildtrees/bzip2/src/1.0.6-8838f21f8e.clean
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Fixing pkgconfig
-- Acquiring MSYS Packages...
-- Acquiring MSYS Packages... OK
-- Fixing pkgconfig - release
-- Checking file: C:/program files/vcpkg/packages/bzip2_x64-windows/lib/pkgconfig/bzip2.pc
CMake Error at scripts/cmake/vcpkg_fixup_pkgconfig.cmake:241 (message):
  Unhandled string
  "files/vcpkg/packages/bzip2_x64-windows/lib/pkgconfig/../../lib" was found!
  If it is a system library use the SYSTEM_LIBRARIES parameter for the
  vcpkg_fixup_pkgconfig call! Otherwise, correct the *.pc file or add the
  case to vcpkg_fixup_pkgconfig
Call Stack (most recent call first):
  scripts/cmake/vcpkg_fixup_pkgconfig.cmake:316 (vcpkg_fixup_pkgconfig_check_files)
  ports/bzip2/portfile.cmake:51 (vcpkg_fixup_pkgconfig)
  scripts/ports.cmake:79 (include)

Error: Building package bzip2:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: bzip2:x64-windows
  Vcpkg version: 2020.06.15-nohash

Additional context
Add any other context about the problem here, such as what you have already tried to resolve the issue.

No error for me. I am using c0f23c6c31ea7af5a751ea48a043dc64a872f4a0.
What compiler do you use?

Compiler does not matter.
Please dont use vcpkg in a path with a space. Especially the make based ports don't like it. The error could be fixed be replacing ${CURRENT_INSTALLED_DIR} with CURRENT_INSTALLED_DIR before the list transformation in vcpkg_fixup_pkgconfig and do it vice versa after the list has been created.

Duplicatd to https://github.com/microsoft/vcpkg/issues/13103, this issue would be fixed by PR https://github.com/microsoft/vcpkg/pull/13126