Extending routablepageurl or creating a new localizedroutablepageurl tag

The routablepageurl tag is fairly crucial in resolving page URLs that are "soft routes" from wagtail.contrib.routable_page, but this tag is not locale-aware and so the following code is simply going to find the /en/ URL, even when the user is on some other locale:
{% routablepageurl home_page 'category-view' cat.slug as cat_url %}

Can we make wagtail-localise wrap-and-reserve this tag such that its invocation is identical but the result is the correctly localized URL? Or, create a separate "sibling" tag that does the same thing as routablepageurl but with the correct locale infix?

I may well be missing something, but isn't this the same situation as a straightforward {% pageurl home_page %} - it depends where your home_page variable came from, and if it's come from somewhere that hasn't already taken locale into account then you have to correct that with {% pageurl home_page.localized %}? Or in this case:
{% routablepageurl home_page.localized 'category-view' cat.slug as cat_url %}

Having said that (and without wishing to derail the topic...), something similar did come up in #support with the {% slugurl %} tag - in that case it seems more clear-cut that the tag should include the .localized step as standard, since unlike pageurl / routablepageurl there's no place to insert a .localized selector when invoking it, and without it slugurl is essentially useless on multi-language sites (since it assumes that the slug in question is globally unique).
Conversation from #support:

David Brewer Jul 31st at 12:15 AM
Beginner question here: if I’m in a Django template and I want to get a link to a Wagtail page whose slug I know, how do I do that? I’ve been poking around the documentation and Stack Overflow trying to figure this out but not having much luck. The closest I’ve gotten is {{ url 'wagtail_serve' 'slug_of_my_page' }}, but when I try that I get an error:

Reverse for ‘wagtail_serve’ with arguments ’(’slug_of_my_page’,)’ not found. 1 pattern(s) tried: [’en/((?:[\w\-]+/)*)$’]

Possibly important detail: this is a localized site, so the url patterns set up in urls.py look like this:
urlpatterns += i18n_patterns(
    url("", include(wagtail_urls)),
)

mattwestcott  6 days ago
David Brewer You want the slugurl tag: https://docs.wagtail.io/en/stable/topics/writing_templates.html#slugurl

David Brewer  6 days ago
AH! Yes, that is a lot, lot simpler.  Thanks so much!
If I’m on a localized site, is there a way to get the url that is returned to include the same locale tag as the page I’m on currently?

mattwestcott  6 days ago
Hmm. I'm not sure how slugurl interacts with multi-language sites, actually - in normal circumstances, slugurl is used on the assumption that there's only one page in the tree with that slug, and if there isn't, exactly which one it chooses will be undetermined. In the case of multi-language sites, I suspect the slug will be duplicated once per language, so it may end up choosing randomly between them...

David Brewer  6 days ago
Ok! I might have to resort to actually making this navigation editable in the CMS so that I can get at proper page instances for each item in the navigation, I suppose. But as a temporary first step, slugurl is a lot better than what I had, so thank you for that pointer.

Richard Allen  3 days ago
hi David, if you're using wagtail-localize, you can use a templatetag to return the locale version of the page represented by the slug: Page.objects.get(slug="myslug").localized

David Brewer  3 days ago
Thanks Richard Allen, appreciated!

Ah, looks like I also filed this on the wrong repo, this was supposed to go in the wagtail-localize repo

@Pomax Looks like @kaedroho moved it here - the main Wagtail repo is the correct place for this, as it relates to the localisation mechanisms in Wagtail core rather than the translation workflow provided by wagtail-localize.

oh interesting. I would have assumed it the exact opposite way: core has no reason to add or update that tag, until wagtail-localize is loaded alongside, making it the wagtail-localize code's responsibility to overload (or offer a second tag) because that functionality is not needed when users don't have wagtail-localize as an installed app?


podman 0.3.3 depends on containernetworking-cni > 0.6, missing from virt7-container-common repo

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
Description
ran into this working on a new Chef cookbook for crio... it worked this morning, broke this afternoon.
podman is currently uninstallable due to a missing containernetworking-cni package > 0.6 in the virt7-container-common repos.
Steps to reproduce the issue:

spin up a cent 7 box

set up the virt7-container-common-candidate repo

try to install podman

Describe the results you received:
Error: Package: podman-0.3.3-1.dev.gitbc358eb.el7.x86_64 (virt7-container-common)
           Requires: containernetworking-cni > 0.6
           Installed: containernetworking-cni-0.5.2-7.el7.x86_64 (@virt7-container-common)
               containernetworking-cni = 0.5.2-7.el7

Describe the results you expected:
podman 0.3.3 successfully installed

@lsm5 Is this something you could look at?

On Thu, Mar 15, 2018 at 12:19:02PM +0000, Daniel J Walsh wrote:

@lsm5 Is this something you could look at?

building here: https://cbs.centos.org/koji/taskinfo?taskID=360043
--
Lokesh
IRC: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5

works again, thank you @rhatdan & @lsm5!

@nathwill Any chance you want to Blog on what you are doing?  We are always looking for bloggers on medium.com/crio

@rhatdan yeah, sounds great! i'm @nathwhal on medium<EMAIL_ADDRESS>if you need to email me anything.

On Thu, Mar 15, 2018 at 06:19:58PM +0000, Nathan Williams wrote:

@rhatdan yeah, sounds great! i'm @nathwhal on medium<EMAIL_ADDRESS>if you need to email me anything.

awesome, thanks! feel free to ping me here or freenode/#centos-virt or
#centos-devel in case of issues with centos packages.
--
Lokesh
IRC: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5


[Modal] The .close.icon disappears on IE11 when using observeChanges or modal('refresh')

Problem
When configuring a modal with observeChanges: true, on Internet Explorer 11 and if the modal's height is bigger than the size of the window, the close icon (.close.icon) seems to disappear. This is also happening when using .modal('refresh').
This is working as intended on Chrome (please see below). I haven't tested on earlier/later versions of IE nor other browsers.
Examples
Please also refer to this fiddle as a demonstration: here
In case you're experiencing some trouble with this fiddle on IE, below is also an example of the code.

      Modal Title

        Modal Content

Cancel

OK

Internet Explorer 11 (notice the close (X) icon missing at the top of the modal)

Chrome (the close (X) icon is present)

I second that, same issue with 2.2.6 and IE 11. Firefox seems ok.
Example:
Imgur

See #4676.


cleanup(pubsub): move from handwritten topic admin to generated in integration tests

Part of https://github.com/googleapis/google-cloud-cpp/issues/12987

This change is

After moving the code, I'm less inclined to removing them. I will consider

Now that I think about it some more, I don't think we should be changing the integration tests for handwritten clients. Yes the clients are deprecated, but we should probably still have tests that verify that they work.
I think you should only use the generated admin clients in code that is not under test. e.g. if we need to use a TopicAdminClient to create a topic for the SubscriptionAdminClient integration tests.

I need to change this to add the [[deprecated]] tags

https://github.com/googleapis/google-cloud-cpp/pull/13677

I need to change this to add the [[deprecated]] tags
There is a way to suppress the deprecation warnings from breaking our builds, e.g.:
https://github.com/googleapis/google-cloud-cpp/blob/8f7b6654c64cbeb623fdfc2f8bbfd82fdabd25ef/google/cloud/spanner/mocks/row.h#L30-L31

I need to change this to add the [[deprecated]] tags

There is a way to suppress the deprecation warnings from breaking our builds, e.g.:
https://github.com/googleapis/google-cloud-cpp/blob/8f7b6654c64cbeb623fdfc2f8bbfd82fdabd25ef/google/cloud/spanner/mocks/row.h#L30-L31

ack

I disagree though. I think we should not use the old client in the tests. When people see that this code exists, they will use it, and it will make deprecating harder.

These files should live on past deprecation, so I am moving them to the generated client. I reverted the sub_admin and topic_admin integration tests so we are still testing handwritten code


Bump rag frontend resource requests

Frontend sometimes gets OOM-killed. Set guaranteed QOS.

/gcbrun

The dangerous part is https://github.com/GoogleCloudPlatform/ai-on-gke/blob/main/applications/rag/frontend/container/cloud_sql/cloud_sql.py#L58 we select all. LOL, I think Julie's change will reduce this issue.


feat!: change from autoware_auto_msgs to autoware_msgs

following change from autoware_auto_msgs to autoware_msgs

Codecov Report
Attention: Patch coverage is 0% with 20 lines in your changes are missing coverage. Please review.

Project coverage is 0.00%. Comparing base (b779f84) to head (1a908ba).
Report is 2 commits behind head on main.

Files
Patch %
Lines

...nterface/src/pacmod_interface/pacmod_interface.cpp
0.00%
16 Missing :warning:

...erface/src/pacmod_steer_test/pacmod_steer_test.cpp
0.00%
3 Missing :warning:

...ace/src/pacmod_interface/pacmod_diag_publisher.cpp
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@          Coverage Diff           @@
##            main     #77    +/-   ##
======================================
  Coverage   0.00%   0.00%
======================================
  Files         11      11
  Lines        981     946    -35
  Branches       0     102   +102
======================================
+ Misses       981     946    -35

Flag
Coverage Δ

differential
0.00% <0.00%> (?)

total
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

I have recreated the PR with the branch that exists in the upstream repository because pre-commit.ci doesn't have access to modify cyn-liu's branch.


Chaincode only accepts the first contract in the export array - Typescript

Chaincode only accept the first contract in the export array.

I've added super to each contract class.

I exported the contracts like this:

I have 2 channels - mychannel & garagecars

I deployed the chaincode to both channels using these commands:

./network.sh deployCC -ccn basic -ccp /home/ajiths/Desktop/chaincode-typescript/ -ccl typescript -ccv 2.0 -c mychannel
/network.sh deployCC -ccn basic -ccp /home/ajiths/Desktop/chaincode-typescript/ -ccl typescript -ccv 2.0 -c garagecars

The first contract (AssetTransferContract) is accessible on both channels, but the other ones are not.
Please advice me.
Version - Latest

The problem might be the way your client application is invoking the smart contract. You need to explicitly request the correct contract within the chaincode package, for example:
const assetTransfer = network.getContract("basic", "AssetTransferContract");
const carGarage = network.getContract("basic", "CarGarageTransfer");

It seems that one of the contracts — for me, the first in the list — is selected as the default contract. The default contract is the one that will be called if you do not explicitly provide the contract name, for example:
const defaultContract = network.getContract("basic");

Note that the two contract share the containing chaincode's namespace within the ledger so will have visibility of each other's ledger entries. If you want the ledger state of the two smart contracts to be separate, you should deploy them in separate chaincode packages.

The problem might be the way your client application is invoking the smart contract. You need to explicitly request the correct contract within the chaincode package, for example:
const assetTransfer = network.getContract("basic", "AssetTransferContract");
const carGarage = network.getContract("basic", "CarGarageContract");

It seems that one of the contracts — for me, the first in the list — is selected as the default contract. The default contract is the one that will be called if you do not explicitly provide the contract name, for example:
const defaultContract = network.getContract("basic");

Note that the two contracts share the containing chaincode's namespace within the ledger so will have visibility of each other's ledger entries. If you want the ledger state of the two smart contracts to be separate, you should deploy them in separate chaincode packages.

@bestbeforetoday   This was the issue. This solved my issue. Thank you.
I have a suggestion as well. It was very hard to find this information in the community. I think we need to include this information in the documentation.

@ajiths10 Which bits of information were missing for you? The client application side is documented in the API documentation:

https://hyperledger.github.io/fabric-gateway/main/api/node/interfaces/Network.html#getContract

It seems that you discovered how to define multiple contracts OK. Again, this is described in the API documentation:

https://hyperledger.github.io/fabric-chaincode-node/main/api/tutorial-using-contractinterface.html
https://hyperledger.github.io/fabric-chaincode-node/main/api/tutorial-deep-dive-contract-interface.html

@ajiths10 Which bits of information were missing for you? The client application side is documented in the API documentation:

https://hyperledger.github.io/fabric-gateway/main/api/node/interfaces/Network.html#getContract

It seems that you discovered how to define multiple contracts OK. Again, this is described in the API documentation:

https://hyperledger.github.io/fabric-chaincode-node/main/api/tutorial-using-contractinterface.html
https://hyperledger.github.io/fabric-chaincode-node/main/api/tutorial-deep-dive-contract-interface.html

I never thought it was on the client side. Anyway, thanks for the support :+1:  . The issue is resolved, so I'm closing this issue.


Add GitHub repository link to user interface

We have access to this icon in our project already: https://icons.getbootstrap.com/icons/github/

Can I take this issue up ?

@Sherwin-14 that would be great! Please let me know if there's anything I can do to support you. I'm thinking the repo URL should be in the constants subpackage, but other than that I don't have any strong opinions about this work :)

Hey! I've been trying to get the latest commit from the master branch to work using the instructions provided on your documentation, I am considerably quite new to Docker so it's a bit hard for me, I am providing you with the logs ttps://paste.rs/SE7Ia

Oh no! Just to double-check, are you working from 4ab3f6b (main branch)?
I updated the docs last night as well. Are you using this page? https://usaon-benefit-tool.readthedocs.io/en/latest/how-to/development.html#
Thanks for sharing the logs. I did some googling and I can't find any mention of libmamba Subprocess call failed: Invalid argument. I attempted a fresh build just now from the latest commit on main, and it succeeded for me.
Can you please share some system info? I'm using:

Ubuntu 22
docker --version:  24.0.5, build ced0996
docker compose version:  v2.20.2

Do you also have at least 2GB of free disk space?

I just pushed another commit on main (ea32471) to upgrade the base micromamba image we're building from. Maybe that will help?
Since I wasn't able to reproduce, I'm just guessing based on the error coming from libmamba.

Hey there! Sure I can share my system info, I also tried this on the latest Fedora release with no success.

Arch Linux
Docker Version: 24.0.7
Docker Compose: 2.23.3

It is currently late so is it alright if I will not be able to check the branch until tomorrow 😓

No problem at all, this feature is not urgent. Please don't feel pressured :) :heart:

Are you on an ARM machine perhaps?

I just reproduced your exact symptom by creating a fresh Fedora VM in DigitalOcean. I'm not really understanding how the pip install step could fail on one distro but not another. The builds are succeeding in GitHub Actions (Ubuntu). There's something weird going on here. If I remove the pip dependencies, the build succeeds.
If you'd like to get going faster, can you comment the build: "." line from the compose.dev.yml file, so a pre-build image from DockerHub is downloaded?

I tried (separately) disabling selinux, and changing the version of the base image to 1.0.0, both reproduced the exact same symptom on the Fedora droplet. I couldn't think of anything else. I was able to get a successful build on a Debian droplet. I'm really confused about this, and I really don't know much about Fedora. I'm sorry I don't have other ideas at the moment. One solution, which takes a lot more work, would be to get our pip dependencies on to conda-forge, since earlier I confirmed removing pip dependencies makes the build succeed.

If you'd like to get going faster, can you comment the build: "." line from the compose.dev.yml file, so a pre-build image from DockerHub is downloaded?

This is still my best suggestion :frowning_face:

I have made the pull request here  #238 :)


Amplify commands has TypeError preventing schema change

Note: If your issue/bug is regarding the AWS Amplify Console service, please log it in the
Amplify Console GitHub Issue Tracker

Describe the bug
I am using Amplify with a React Native Project. I am realizing that I am not able to use Amplify commands on the CLI without an error:
TypeError: Cannot read property 'forEach' of undefined     at AmplifyToolkit.showHelpfulProviderLinks [as _showHelpfulProviderLinks] (/usr/local/lib/node_modules/@aws-amplify/cli/lib/extensions/amplify-helpers/show-helpful-provider-links.js:12:15)     at processTicksAndRejections (internal/process/task_queues.js:97:5)     at async Object.exports.run (/usr/local/lib/node_modules/@aws-amplify/cli/lib/commands/status.js:6:5)     at async Object.executeAmplifyCommand (/usr/local/lib/node_modules/@aws-amplify/cli/lib/index.js:173:9)     at async executePluginModuleCommand (/usr/local/lib/node_modules/@aws-amplify/cli/lib/execution-manager.js:153:5)     at async Object.executeCommand (/usr/local/lib/node_modules/@aws-amplify/cli/lib/execution-manager.js:35:9)     at async Object.run (/usr/local/lib/node_modules/@aws-amplify/cli/lib/index.js:82:9)
Amplify CLI Version
4.32.1
To Reproduce
Amplify status or Amplify push
Expected behavior
Amplify status will work, but show the error. Amplify push will fail because of this error.
Desktop (please complete the following information):

OS: Mac
Node Version: v12.18.4

Hi @elcain, can you try upgrading to the latest version of the CLI and see if you're still hit this error?
npm install -g @aws-amplify/cli

Hi @jhockett so I went ahead and upgraded. Now if I issue a command I get something that says:
Amplify has been upgraded to handle secrets more securely by migrating some values in team-provider-info.json to deployment-secrets.js on You can create a back up of the team-provider-info.json file before proceeding.
If I hit no, the command just stops. If I hit yes, I get another error:
Error: File at path: '/Users/elijahcain/Documents/Sonar-current/amplify/backend/auth/sonarbdbce738/parameters.json' does not exist     at Function.JSONUtilities.readJson (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-cli-core/lib/jsonUtilities.js:40:19)     at StateManager.getData (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-cli-core/lib/state-manager/stateManager.js:215:56)     at StateManager.getResourceParametersJson (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-cli-core/lib/state-manager/stateManager.js:112:25)
I'm not sure what this parameters.json file is.

Here's the docs on describing the parameters.json file: https://docs.amplify.aws/cli/reference/files#parametersjson
Those files are used for passing in values to the cloudformation templates.
Can you try creating an empty json file and then see if that allows you to continue?
echo '{}' > /Users/elijahcain/Documents/Sonar-current/amplify/backend/auth/sonarbdbce738/parameters.json

hmm ok when I go to the path up to backend, I actually don't have a Auth folder.

@elcain what categories are you trying to use? Did you delete anything manually?

@jhockett I don't believe I deleted anything manually. I am using the Amplify Auth library, but not in the branch. I switched to my branch where I am using the Auth library and even there I do not have a Auth folder.

@elcain Do you have a json structure that looks like this in you team-provider-info.json?

@ammarkarachi it does have that json.

Hi @elcain, can you please try running amplify pull --restore to restore your environment to the last pushed state?

Hey @jhockett so I just get the same error when I try and restore. I was looking back and the commits, and the Auth folder WAS accidentally deleted. Is there a way to re-generate the folder?

I just saw this same error (I believe) with a newer version of Amplify: 4.42.0.
I noticed this error pop up just after an upgrade from some months-old version of the cli to version 4.42.0.
Here's my transcript of (seemingly) the same error:

Current Environment: dev

| Category | Resource name                      | Operation | Provider plugin   |
| -------- | ---------------------------------- | --------- | ----------------- |

...

Tag Changes Detected
Cannot read property 'forEach' of undefined
TypeError: Cannot read property 'forEach' of undefined
    at AmplifyToolkit.showHelpfulProviderLinks [as _showHelpfulProviderLinks] (/usr/local/lib/node_modules/@aws-amplify/cli/lib/extensions/amplify-helpers/show-helpful-provider-links.js:12:15)
    at processTicksAndRejections (internal/process/task_queues.js:88:5)
    at async Object.exports.run (/usr/local/lib/node_modules/@aws-amplify/cli/lib/commands/status.js:6:5)
    at async Object.executeAmplifyCommand (/usr/local/lib/node_modules/@aws-amplify/cli/lib/index.js:216:9)
    at async executePluginModuleCommand (/usr/local/lib/node_modules/@aws-amplify/cli/lib/execution-manager.js:166:5)
    at async Object.executeCommand (/usr/local/lib/node_modules/@aws-amplify/cli/lib/execution-manager.js:35:9)
    at async Object.run (/usr/local/lib/node_modules/@aws-amplify/cli/lib/index.js:92:9)
dtal@thing5: amplify -v
4.42.0

@jhockett - I just tried your suggestion right after receiving this error and got another error. It's strange it reports "environment 'dev' not found because I did not remove that environment. Here is the new error trying to run your suggested cli command amplify pull --restore, then trying to add env because it seems to need it, and getting the error:
dtal@thing5: !2034
amplify pull --resotre
Environment 'dev' not found.
Try running "amplify env add" to add a new environment.
If this backend already exists, try restoring its definition in your team-provider-info.json file.
dtal@thing5: amplify env add
Note: It is recommended to run this command from the root of your app directory
? Do you want to use an existing environment? Yes
? Choose the environment you would like to use: dev
Using default provider  awscloudformation
init failed
TypeError [ERR_INVALID_ARG_TYPE]: The 'request' argument must be string. Received type undefined
    at onSuccess (/usr/local/lib/node_modules/@aws-amplify/cli/lib/init-steps/s9-onSuccess.js:53:28)
    at Object.exports.run (/usr/local/lib/node_modules/@aws-amplify/cli/lib/commands/init.js:29:19)
    at processTicksAndRejections (internal/process/task_queues.js:88:5)
dtal@thing5:

Hey @jhockett so I just get the same error when I try and restore. I was looking back and the commits, and the Auth folder WAS accidentally deleted. Is there a way to re-generate the folder?

@elcain if the folder exists in an old git commit, you should be able to retrieve it from git.

@dorontal do you know what version you upgraded from? Is the file team-provider-info.json present in the amplify folder?

@jhockett Unfortunately I lost that information. Just checked the shell history and noticed that it was something installed around last summer via pip3 and resided in /usr/bin/aws, while the new one is all in /usr/local/bin.  Right now, however, I am rebuilding the entire project from scratch, just to make sure I did not report the above for some silly reason, trying to reproduce the problem to be sure it still exists -- will report once that is done.

@jhockett yup once I got that folder back I was able to use amplify pull --restore and everything works fine now.

Glad to hear everything has been resolved!


Add new procedure on adding a node to a Sawtooth network

Includes Docker and Ubuntu (but not AWS, because AWS is only 0.8).

Still needs information on how to verify network functionality - see the last section.

Signed-off-by: Anne Chenette<EMAIL_ADDRESS>

The Docker Compose file for this procedure is in PR #1534

Pushed a fix to make Dan's corrections to the endpoint info & 8800 port numbers. This fix also reformats the the Docker container info for clarity, adds Docker & Ubuntu steps to set the transaction families on the first validator node, shows the Ubuntu start-component steps for validator node 2, and fixes several egregious typos.

When I try the command
`sawset proposal create \

sawtooth.validator.transaction_families='[{"family": "intkey", "version": "1.0"},
{"family":"sawtooth_settings", "version":"1.0"}
{"family":"xo", "version":"1.0"}
{"family":"sawtooth_validator_registry", "version":"1.0"}]'

I get on both my VMs that I tried it on the erro
Error: Unable to read key file: [Errno 2] No such file or directory: '/home/user/.sawtooth/keys/user.priv
I have the keys in the correct directory and I used path.toml also just to be sure for the paths.

I pushed a fix-up commit with reviewer corrections and related changes.
Note: I also changed the Ubuntu install procedure - I moved the user and root keygen commands to their own steps.  This should help clarify that both keygen steps are needed on the second validator node.

Pushed another fix-up commit - this one adds "intkey set" and "intkey show" examples at the end. It also fixes minor formatting and wording issues.

Pushed another fix that substantially rewrites this section. The Ubuntu steps now have a substantial "Prerequisites" section that explain the bind and endpoint info. Also, the config file steps have been replaced with simpler command-line options. There's much more, but that's the high-level summary.

@sofiter - Thanks for your comment - it prompted us to re-evaluate whether this complicated command belonged in this procedure.  As a result, we deleted the "sawnet proposal create" command from this procedure (and other procedures), because we felt there wasn't a need to limit the allowed transaction types in this application development environment. Note that information on this setting will move to the Transaction Family Specification in an upcoming PR, but isn't there yet. In the meantime, the Architecture chapter has some information on this setting.
But if you'd still like to run this command, I think there might be some missing commas in the command you show in your comment.  (Sorry - that was my error in the version that you commented on.) I think it should be something like this:
 ``sawset proposal create sawtooth.validator.transaction_families='[{"family": "intkey", "version": "1.0"},{"family":"sawtooth_settings", "version":"1.0"},{"family":"xo", "version":"1.0"},{"family":"sawtooth_validator_registry", "version":"1.0"}]'``

Also, my local expert suspects there might be a problem with your public/private keypair - he wonders if they got generated by root instead of by your username. (So they might be in the wrong location.)
Anyway, if you'd like more help with this issue, please go to the #sawtooth channel on Rocket Chat; - the folks there can help you directly. https://chat.hyperledger.org/channel/sawtooth


Offcanvas:  activate focustrap when backdrop is enabled

closes #36596
Preview https://deploy-preview-36717--twbs-bootstrap.netlify.app/
/cc @patrickhlauke

Added https://github.com/twbs/bootstrap/pull/36717/commits/658045e9aa70ecd9ce98c838e2c69b3acc171f7c to tackle the 3rd point from the issue:

Also noticed that focus is not moved to either of the off-canvases (the docs nav, and the general nav), but remains on the toggle buttons. Not looked at the markup in depth, but suspect a tabindex="-1" is missing on them (compare to the working off-canvas examples https://getbootstrap.com/docs/5.2/components/offcanvas/).

To test it in the docs, simply focus the main header (keyboard), open both menus with 'Enter' and then press to 'Escape' to close them. 'Escape' didn't do anything before since offcanvases didn't get the focus. Now it's working.

If I have well understood the 2nd point in the issue, it is safe to remove aria-expanded="false" from the .navbar-togglers in the docs since offcanvases won't change the status and make an aria-expanded="true".
Done via https://github.com/twbs/bootstrap/pull/36717/commits/d8f192dc9451957efb48057f43e98085c57270df.

Looking good, and correctly addresses the issue https://github.com/twbs/bootstrap/issues/36596
At a higher level though, I'm wondering if we should just always enable focus trapping? Or, if we do want to allow non-modal offcanvases, we should document this clearly in the docs (currently it seems the docs are silent about focus behaviour at all) and also make sure that aria-modal="true" is only added when it's intended to be a modal offcanvas

At a higher level though, I'm wondering if we should just always enable focus trapping? Or, if we do want to allow non-modal offcanvases, we should document this clearly in the docs (currently it seems the docs are silent about focus behaviour at all) and also make sure that aria-modal="true" is only added when it's intended to be a modal offcanvas

Either way, an offcanvas that doesn't scroll or has a backdrop, behaves like modal, so I think is right for know.
BUT yes, we may, can discuss it for next releases


Allow adding allowed values to existing attributes

I've come to code where custom onclick is added to a-Tags.
TYPO3 already ads an onclick to allow list for a-Tags.
I could not find any way to add another allowed value to the list.
Looks like the code is too robust to allow me to add or alter the already configured behaviour.
I only could remove the already build a-Tag and build it from scratch / from reading original values excluding the onclick and rebuilding it again?
Do I overlook something here? How should a developer use the library in such situation, where a framework already adds configuration?
That's our code which is just not called, because TYPO3 onclick value already does not match. Further values are not checked anymore. I couldn't find a way to check whether at least one value matches.
class DefaultSanitizerBuilder extends Typo3DefaultSanitizerBuilder
{
    protected function createBasicTags(): array
    {
        $tags = parent::createBasicTags();
        // Allow onlick="econdaTrackMarker();" in addition to TYPO3 native onclick code.
        $tags['a']->getAttr('onclick')->addValues(new RegExpAttrValue('#^econdaTrackMarker\(#'));
        return $tags;
    }
}

@DanielSiepmann Looking forward to receiving your feedback on PR #66 (which makes mentioned core change above obsolete)

Adding new Tag::removeAttr($name) and (maybe) Attr::setFlags($flags) methods to this library seems to be useful as well.

Do you have any idea if and when that will be added?


Add check and ci-check targets to Make

Fixes #896.
Reviews are welcome! If no issues are raised, I'll merge this in three days.

Coverage remained the same at 57.038% when pulling ed13e8e2a57f4655acdfd0036e658e33e8861ae9 on feature/896-make-check-and-make-ci into 6157052aa6c8f999b21d502d4b605574b8884529 on master.

Both new targets work here.

Okay, thanks! I'm squashing those fixups then.


can you make scrcpy work on ip stream .like play on live on any browser and media player

Hello dudo,That Question is what i wanna ask！

this project uses adb forward socket,so,it probably can not provide ip video stream

See https://github.com/Genymobile/scrcpy/issues/313


Support to Set and Map with '_.size'

This allows '_.size' for 'Map' and 'Set'.
Example:
let e = new Set();

e.add(1);
e.add(13);
e.add(12);

_.size(e);

Coverage increased (+0.005%) to 96.301% when pulling bb304583243689baeb85cb1e198797ff608b04fb on JonDotsoy:v1.9.0 into d9f4f7648ff38c86cc7456e42df9bd7b97847df4 on jashkenas:v1.9.0.

Should we be getting emails from coveralls, or other CI services?  Is there a way to restrict (or, perhaps opt out of) automatic CI emails, while still getting the rest?

Yeah where did the coveralls coverage come in? @jridgewell @megawac @michaelficarra did any of yall turn it on?

Not me.

Move :arrow_right: #2476


Wildcard object privileges not listing for MariaDB/MySQL

System information:

Operating system (distribution) and version
Ubuntu 19.10
DBeaver version
<IP_ADDRESS>001191557
Additional extensions

Connection specification:

Database name and version
MariaDB 10.2
Driver name
MariaDB
Do you use tunnels or proxies (SSH, SOCKS, etc)?
Yes

Describe the problem you're observing:
User Privileges on wildcard objects are not listed when selecting the Catalog and Tables, the Table Privileges only list non-wildcard privileges.
MariaDB/MySQL allows wildcards in the 'ON' and 'TO' parts of a GRANT. Privileges with wildcards in the 'ON' part are not showing in DBeaver.
Relevant documentation on wildcard privileges: https://dev.mysql.com/doc/refman/5.6/en/grant.html#grant-quoting
Steps to reproduce, if exist:
This presumes you have default 'test' user and 'test' database, and 'test' user is not granted ALTER privileges.
Grant ALTER on all tables in databases named 'test*':
GRANT ALTER ON `test%`.* TO 'test'@'%';
FLUSH PRIVILEGES;

Refresh/Reconnect DBeaver and open the privileges for user 'test'@'%' and database named 'test': ALTER privilege is not listed.
Include any warning/errors/backtraces from the logs

thanks for the bug report

Hi,
I have the same problem.
Tried version 6.3.1 6.3.3 and 6.3.5

Fixed

verified

Hi,
Not sure it is fixed.
Here is a screenshot under6.1.1

Here is the same screenshot under 7.0.0


Don't create a dask cache if it doesn't exist

Description
I've mentioned before that our default handling of dask caching can be problematic, both when debugging dask issues and when using the Play button (when the cache actually hinders performance). It also seems like the dask cache is leaking memory.
So this PR simply does away with the automatic creation of the cache. Users still have the ability to create it with napari.resize_dask_cache(mem_fraction=0.1). I'll add this point to the dask tutorial in a separate PR.
References
Closes #2329

Ok I've fixed the tests except one, which should be fixed but I'm super confused as to why it isn't:
_____________________ test_dask_array_doesnt_create_cache ______________________

    def test_dask_array_doesnt_create_cache():
        """Test that adding a dask array creates a dask cache and turns of fusion."""
        # by default we have no dask_cache and task fusion is active
        original = dask.config.get("optimization.fuse.active", None)

        def mock_set_view_slice():
            assert dask.config.get("optimization.fuse.active") is False

        layer = layers.Image(da.ones((100, 100)))
        layer._set_view_slice = mock_set_view_slice
        layer.set_view_slice()
        # adding a dask array won't create cache, but will turn off task fusion.
        assert utils.dask_cache is None
        assert dask.config.get("optimization.fuse.active", None) == original

        # if the dask version is too low to remove task fusion, emit a warning
        _dask_ver = dask.__version__
        dask.__version__ = '2.14.0'
        with pytest.warns(UserWarning) as record:
            _ = layers.Image(da.ones((100, 100)))

        assert 'upgrade Dask to v2.15.0 or later' in record[0].message.args[0]
        dask.__version__ = _dask_ver

        # make sure we can resize the cache
        utils.resize_dask_cache(10000)
>       assert utils.dask_cache.cache.total_bytes > 1000
E       assert 0 > 1000
E        +  where 0 = <cachey.cache.Cache object at 0x7fd5524ed340>.total_bytes
E        +    where <cachey.cache.Cache object at 0x7fd5524ed340> = <dask.cache.Cache object at 0x7fd5524e4490>.cache
E        +      where <dask.cache.Cache object at 0x7fd5524e4490> = utils.dask_cache

napari/layers/_tests/test_dask_layers.py:38: AssertionError

Any ideas??? The two lines speak for themselves in their bafflingness.

I'm fine with this, but am wondering if we should put the cache size as a setting that could be modified in the GUI? We can wait on that, but it also feels like a natural thing to do now. If someone really wants to have the cache on it should probably persist, otherwise they will have to turn it on in every script. What does everyone else think? I think it will make this change much more gentle for our users who want the cache

I'm fine with this, but am wondering if we should put the cache size as a setting that could be modified in the GUI (i.e. in our preferences dialog)?

Sure :)

@sofroniewn

am wondering if we should put the cache size as a setting that could be modified in the GUI (i.e. in our preferences dialog)?

Yup, good call. I've created #2594 to track this.

Yup, good call. I've created #2594 to track this.

Ok nice, curious if people think we can come to a consensus easily enough there that we could even add that to this PR, which would prevent any breaks in peoples flows. I worry a little bit about merging this without providing the setting at the same time

@sofroniewn I think we should merge this as is. It was, imho, always a bad idea to create the cache automagically. It's resulted in all kinds of unexpected behaviour (weird dask errors, poor performance when using the play button, RAM filling up). And if anyone wants to get the behaviour back, they just need to insert napari.resize_dask_cache(mem_fraction=0.1) into their scripts. We can add that to the release notes.


⚠ Fortnite has degraded performance

In f91e4d7, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1537 ms

Resolved: Fortnite performance has improved in e060f8e.


started of a domain

So this is busted at the moment, but trying to shake out if it's worth it. Downside of domains is (if you don't use the primary_domain config) is that the tag becomes tag:tags:: or the like. Upside is I think it makes stuff like #66 easier b/c it's another directive in the domain and has access to the same shared list. Also if I can get this working, then tag_1 etc becomes the cross reference.

Looks like a good start! It seems like this is probably Sphinx's recommended way of doing things like our tags index page.
Since that would be a breaking change, though, it would be good to support both the new domain original tags directive for awhile, and show DeprecationWarning for the latter. And then maybe remove that later on after a major version bump?
One way to do this would be:

Copy __init__.py from 1.3.1 to a separate module, say _compat.py
Remove setup() from that module
Add a DeprecationWarning to update_tags()
Add to the current __init__.py something like:

from _compat import TagLinks as TagLinksDirective
from _compat import update_tags as update_tags_directive

...

def setup(app):
    ...
    app.connect("builder-inited", update_tags_directive)
    app.add_directive("tags", TagLinksDirective)
    app.add_domain(TagDomain)

Alternatively, we could also do something simple but terrible like a str.replace("tags::", "tag:tags::") on the whole document before it's parsed 😬


Perfomance category suggestion

After finding a solution to this problem I had https://github.com/hyprwm/Hyprland/issues/3959 I thought it would be a good idea to document it so other people know what to do if they stumble upon the same problem. Not only that, I also believe that it would be great to have such category in the hyprland wiki where tricks and known solutions could be documented for people who seek to get more performance out of hyprland.
For now, there is only fix for fractional scaling from the mentioned issue. Though I believe that this page would be very useful when more stuff gets added to it.
Any suggestions or recommendations would be appreciated!

why not slap it into FAQ like we do with battery-drain related stuff?

why not slap it into FAQ like we do with battery-drain related stuff?

I was thinking that it would suit configuration more because in the end it would be basically telling you how to configure something to boost performance. However, if you believe that it would suit FAQ more then I can change that.

why not slap it into FAQ like we do with battery-drain related stuff?

I was thinking that it would suit configuration more because in the end it would be basically telling you how to configure something to boost performance. However, if you believe that it would suit FAQ more then I can change that.

Also to add. There may be a lot of ways to boost performance and it might be too big for FAQ. That's also why I thought it would fit more into configuring.

fair enough, then move them

Done, what do you think?

Alright I made the changes. Does it look good or did I make some mistake?

@vaxerski So what do you think? Is it fine now or should I change something.

sorry I am just really busy this week and missed this


Update tests to not use TestUtils.getFreePort() and so ensure we not …

…try to use a port that is used by the system in the meantime.
Motivation:
We should not try to detect a free port in tests put just use 0 when bind so there is no race in which the system my bind something to the port we choosen before.
Modifications:

Remove the usage of TestUtils.getFreePort() in the testsuite
Remove hack to workaround bind errors which will not happen anymore now

Result:
Less flacky tests.

@normanmaurer - please address the build failures

@Scottmitch fixed everything... PTAL again

@Scottmitch all addressed... PTAL again

Cherry-picked into 4.1 (3cdff36821) and 4.0 (928a9e9eaa)


Modified the documentation to include requirements.txt for easy installation.

Pre-Checklist:

[x]  I have read the docs.
[x]  My code is well-commented and adheres to the project's coding standards.

Description:
This PR addresses the issue highlighted in https://github.com/MzeroMiko/VMamba/issues/22. It introduces a series of enhancements and bug fixes to the VMamba project, including improvements to the FLOPs calculation algorithm and the addition of new features for model training and analysis tools.
Related Issues:
open #22
New Behavior:
With the changes made in this PR, users can follow our installation and usage steps to get started more easily. And Star History is added to show the hotness of the project.

前置检查清单:

[x]  我已经阅读了文档。
[x]  我的代码进行了充分的注释，并遵循了项目的编码标准。

描述:
此PR解决了中提出的问题https://github.com/MzeroMiko/VMamba/issues/22。它为VMamba项目引入了一系列的增强和错误修复，包括改进FLOPs计算算法以及为模型训练和分析工具添加新特性。
相关问题:
开启#22
新的行为:
通过此PR所做的更改，用户可以按照我们的安装使用步骤比较轻易的入门。且加入了Star History来展示项目的热度。

I'm so happy that u merged my modifications (^▽^)， I will keep contributing!


Add CONTRIBUTING.md

GitHub supports contributing guidelines:
https://github.com/blog/1184-contributing-guidelines
We should add some to this repository

Done.


Search simply doesn't work at all.

Description
Search simply does not work, it may be after a certain line number, I'm unsure, but it's always when I'm editing code.
Steps to Reproduce

Get an insanely long file
Search for something in it
No results found, despite it being in the file

Expected behavior:
It should be able to find what I ask it to
Actual behavior:
It claims there are no results found
Screenshots:

Versions
Atom    : 1.12.5
Electron: 1.3.9
Chrome  : 52.0.2743.82
Node    : 6.5.0
apm  1.12.9
npm  3.10.5
node 4.4.5
python
git
visual studio 2015

You are searching for SUFI_Map_ar_baggage, where in your file is SFUI_Map_ar_baggage. What's the problem then xD ?

@undefinedvar directly above the search bar.

You have a typo in your search string... the text clearly contains SFUI_Map_ar_baggage, but you are searching for SUFI_Map_ar_baggage. This is exactly what @undefinedvar was trying to tell you.

Corrected my screenshot. Straight copy/paste from the string above:

OK, looks like this is an actual bug/limitation, but since searching is handled by the find-and-replace package, please re-open the issue there (with the correct screenshot).
I'm unsure if the limitation is directly controlled in that package due to markers and highlighting being disabled on large files, or some file length check in the package. Regardless, there issue belongs in that repo, and if it turns out to be a limitation in Atom core, we'll have to implement some type of informative message in the find-and-replace package to make the user aware of the (current) limitation.
Thanks!

Done.


feat: removing the test GitHub profiles.

Deleting the two contributors that were used as example.

Duplicate of #66


Enhancement: Threaded Queue Mode for CamGear Class

PR Summary:
This PR introduces Threaded Queue Mode for CamGear Class(works with VideoGear Common Class too), that enables Blocking use of the source in Fixed-Length Video Streams. This Mode is enabled by default for any Videocapture stream(except any connected Camera/H.W devices).
Manually Disabling/Enabling of Threaded Queue Mode:
To manually alter this mode, CamGear Class now provides THREADED_QUEUE_MODE user-defined flag. This flag can be easily set to True(to enable) or unset to False(to disable) this mode by passing this parameter to **options dict of CamGear class as follows:
options = {'THREADED_QUEUE_MODE': False} #to disable Threaded Queue Mode

Features:

Enables Blocking, Sequential and Threaded LIFO Frame Handling.
It Sequentially adds and releases frames to/from deque and handles the overflow of this queue.
It utilizes deques that support thread-safe, memory efficient appends and pops from either side of the deque with approximately the same O(1) performance in either direction.
Requires less RAM at due to buffered frames in the deque.

Drawbacks:

Direct Colorspace conversion/manipulation may result in delayed/incorrect results, only when this mode is activated
Cannot be applied to Camera Feed/H.W. Devices.

Solves:
#20
TODO

[x] Implement a Blocking Mode in CamGear Class with a threaded queue
[x] Use collections.deque() for performance consideration
[x] Add a test for this Mode
[x] Update Wiki
[x] Fix Bugs and robust testing of this implementation.

@abhiTronix  a very nice implementation here. I am currently comparing performance between libraries like this.
I have read and understand: https://abhitronix.github.io/vidgear/latest/bonus/TQM/#b-monitors-fix-sized-deques
An alternative to a deque here would be a threading.Queue(), but I was wondering if there is a reason you chose a deque over a Queue()?
Comparing the performance of this FileVideoStream using a threading.Queue() and CamGears threaded queue mode, it seems that sometimes the FileVideoStream performs better, and sometimes CamGears performs better. For example:
On a 720x480 H264 mkv file over 1000 frames:
When the main process is doing CPU heavy tasks:
baseline_benchmark: time_for_all_frames: FPS<PHONE_NUMBER>6287495
imutils_benchmark: time_for_all_frames:  FPS =<PHONE_NUMBER>8315772
camgears_benchmark: time_for_all_frames: FPS = 89.56978782677967

When the main process is doing I/O heavy tasks i.e. emulated with a time.sleep():
baseline_benchmark: time_for_all_frames:  FPS =<PHONE_NUMBER>690392
imutils_benchmark: time_for_all_frames:  FPS =<PHONE_NUMBER>1401803
camgears_benchmark: time_for_all_frames: FPS =<PHONE_NUMBER>4731576

Currently scratching my head trying to understand why a queue would behave so differently to a deque, or if its something else in the implementation details causing this difference.

@abhiTronix  a very nice implementation here. I am currently comparing performance between libraries like this.
I have read and understand: https://abhitronix.github.io/vidgear/latest/bonus/TQM/#b-monitors-fix-sized-deques
An alternative to a deque here would be a threading.Queue(), but I was wondering if there is a reason you chose a deque over a Queue()?
Comparing the performance of this FileVideoStream using a threading.Queue() and CamGears threaded queue mode, it seems that sometimes the FileVideoStream performs better, and sometimes CamGears performs better. For example:
On a 720x480 H264 mkv file over 1000 frames:
When the main process is doing CPU heavy tasks:
baseline_benchmark: time_for_all_frames: FPS<PHONE_NUMBER>6287495
imutils_benchmark: time_for_all_frames:  FPS =<PHONE_NUMBER>8315772
camgears_benchmark: time_for_all_frames: FPS = 89.56978782677967

When the main process is doing I/O heavy tasks i.e. emulated with a time.sleep():
baseline_benchmark: time_for_all_frames:  FPS =<PHONE_NUMBER>690392
imutils_benchmark: time_for_all_frames:  FPS =<PHONE_NUMBER>1401803
camgears_benchmark: time_for_all_frames: FPS =<PHONE_NUMBER>4731576

Currently scratching my head trying to understand why a queue would behave so differently to a deque, or if its something else in the implementation details causing this difference.

When the main process is doing I/O heavy tasks i.e. emulated with a time.sleep():When the main process is doing CPU heavy tasks:
baseline_benchmark: time_for_all_frames: FPS<PHONE_NUMBER>6287495
imutils_benchmark: time_for_all_frames:  FPS =<PHONE_NUMBER>8315772
camgears_benchmark: time_for_all_frames: FPS = 89.56978782677967

Actually deque is not slower at all but you're seeing one side of the coin. I purposely added this behavior to avoid frame skipping bug  that goes something like this:

Currently, CamGear(or common VidGear Class) uses separate threads to process frames from the given source at certain high speed one after another, let's say, 50fps(50 frames per second). Now for a video source, imagine we are performing a heavy computational task where the frames are being processed at 5fps only. Under these conditions due to multi-threaded frame capturing, CamGear will keep on cycling frames from the source at 50fps in the background even while no one is requesting for them and thereby finally end up returning a NoneType frame at the output if video file(as source) is of fixed length. This erroneous behavior also leads to the wrong frame being processed at any given instance and another undesired behavior called Frame Skipping

So if there's a blockage on main thread (such as time.sleep()) VidGear's smart APIs blocks the Frame-Extractor thread too:
https://github.com/abhiTronix/vidgear/blob/7018d166ddcdb5f585225b79cf87d0ef335cb550/vidgear/gears/camgear.py#L344-L349
thereby achieving maximum stability.
In reality, all single-element methods on deque are atomic and thread-safe.  So a deque is ~20x faster than Queue (which also uses a deque under the hood) and unless you don't need the "comfortable" synchronization API (blocking / timeout), the strict maxsize obeisance or the "Override these methods (_put, _get, ..) to implement other queue organizations" sub-classing behavior, Or when you take care of such things yourself (like in VidGear), then a bare deque is a good and efficient deal for high-speed inter-thread communication.
VidGear is faster, reliable and function rich all at same time, than its imutils's VideoCapture counterpart. 😉

When the main process is doing I/O heavy tasks i.e. emulated with a time.sleep():When the main process is doing CPU heavy tasks:
baseline_benchmark: time_for_all_frames: FPS<PHONE_NUMBER>6287495
imutils_benchmark: time_for_all_frames:  FPS =<PHONE_NUMBER>8315772
camgears_benchmark: time_for_all_frames: FPS = 89.56978782677967

Actually deque is not slower at all but you're seeing one side of the coin. I purposely added this behavior to avoid frame skipping bug  that goes something like this:

Currently, CamGear(or common VidGear Class) uses separate threads to process frames from the given source at certain high speed one after another, let's say, 50fps(50 frames per second). Now for a video source, imagine we are performing a heavy computational task where the frames are being processed at 5fps only. Under these conditions due to multi-threaded frame capturing, CamGear will keep on cycling frames from the source at 50fps in the background even while no one is requesting for them and thereby finally end up returning a NoneType frame at the output if video file(as source) is of fixed length. This erroneous behavior also leads to the wrong frame being processed at any given instance and another undesired behavior called Frame Skipping

So if there's a blockage on main thread (such as time.sleep()) VidGear's smart APIs blocks the Frame-Extractor thread too:
https://github.com/abhiTronix/vidgear/blob/7018d166ddcdb5f585225b79cf87d0ef335cb550/vidgear/gears/camgear.py#L344-L349
thereby achieving maximum stability.
In reality, all single-element methods on deque are atomic and thread-safe.  So a deque is ~20x faster than Queue (which also uses a deque under the hood) and unless you don't need the "comfortable" synchronization API (blocking / timeout), the strict maxsize obeisance or the "Override these methods (_put, _get, ..) to implement other queue organizations" sub-classing behavior, Or when you take care of such things yourself (like in VidGear), then a bare deque is a good and efficient deal for high-speed inter-thread communication.
VidGear is faster, reliable and function rich all at same time, than its imutils's VideoCapture counterpart. 😉

@bml1g12 You can disable this Threaded Queue Mode easily and achieve sheer performance on benchmarks, but that comes at expense of bugs. So choose wisely.

@bml1g12 You can disable this Threaded Queue Mode easily and achieve sheer performance on benchmarks, but that comes at expense of bugs. So choose wisely.

@bml1g12 Also, Can you benchmark with various maxlen sizes in CamGear?

@bml1g12 Also, Can you benchmark with various maxlen sizes in CamGear?

Thanks for your response.
I think this is the code that had the frame skipping bug prior to your improvement and fix: https://github.com/abhiTronix/vidgear/blob/0e55ead5990149958a1167e74b2ce4062cca8ea9/vidgear/gears/camgear.py but I believe this bug was due to accessing the slave thread self.frame attribute directly i.e. in a non-thread safe way.  I believe the same frame-skipping issues should not apply in either the imutils implementation or the modified camgears-to-queue implementation as the use of a queue guarantees that when the queue is full the slave "reading" thread blocks. It also ensures that None types (due to reaching the end of file) would not be provided to the master thread before the end of the file.

In reality, all single-element methods on deque are atomic and thread-safe. So a deque is ~20x faster than Queue (which also uses a deque under the hood) and unless you don't need the "comfortable" synchronization API (blocking / timeout), the strict maxsize obeisance or the "Override these methods (_put, _get, ..) to implement other queue organizations" sub-classing behavior, Or when you take care of such things yourself (like in VidGear), then a bare deque is a good and efficient deal for high-speed inter-thread communication.

I see, that explains why it is faster in the I/O bound case than all other implementations. But I am don't understand why it would explain in the CPU bound case it is so much slower here. We have two threads:

Main thread - calling CamGears' .read() method
Slave thread - doing the video reading.

In the benchmark, I emulate CPU bound versus I/O bound cases by getting the main thread (i.e. not the camgears code, but the code that would be the actual software) by calling blocking_call() on the obtained frame from camgears as follows:
def blocking_call(io_limited, duration=0.001):
    """Emulating a time consuming process
    :param float duration: how long to block for
    :param bool is_io_limited: If True, will use time.sleep() to emulate an I/O limited producer.
    If False will use a CPU heavy calculation to emulate a CPU limited producer.
    """
    if io_limited:
        time.sleep(duration)
    else: # cpu bound emulation
        time1 = time.time()
        while True:
            _ = 999*999
            time2 = time.time()
            if (time2-time1) > duration:
                break

In both the I/O limited case and the CPU bound case, we would expect the camgears slave reading-thread to have a full queue and sleep, but that should not affect the FPS I am measuring here - as I am measuring the speed of the main thread at obtaining frames. I would have expected that in both cases, as there is a full queue, the main thread should be able to obtain items from the dequeue near-instantly.
Interestingly, switching out the deque for the Queue in the camgears implementation results in an implementation faster than imutils in both I/O and CPU limited cases, given this should be thread-safe, it seems more robust to different use cases to me. Albeit as you say, the deque implementation does offer a small speed boost in the I/O limited case over a queue (about 2% when I ran it over 3 repeats):
baseline_benchmark: time_for_all_frames: = 2.579 +/- 3.6474 or FPS = 387.638
imutils_benchmark: time_for_all_frames: = 5.396 +/- 0.0261 or FPS = 185.308
camgears_benchmark: time_for_all_frames: = 5.208 +/- 0.0076 or FPS = 191.998
camgears_with_queue_benchmark: time_for_all_frames: = 5.343 +/- 0.0036 or FPS = 187.148

Thanks for your thoughts, interested to understand this one deeply!

Thanks for your response.
I think this is the code that had the frame skipping bug prior to your improvement and fix: https://github.com/abhiTronix/vidgear/blob/0e55ead5990149958a1167e74b2ce4062cca8ea9/vidgear/gears/camgear.py but I believe this bug was due to accessing the slave thread self.frame attribute directly i.e. in a non-thread safe way.  I believe the same frame-skipping issues should not apply in either the imutils implementation or the modified camgears-to-queue implementation as the use of a queue guarantees that when the queue is full the slave "reading" thread blocks. It also ensures that None types (due to reaching the end of file) would not be provided to the master thread before the end of the file.

In reality, all single-element methods on deque are atomic and thread-safe. So a deque is ~20x faster than Queue (which also uses a deque under the hood) and unless you don't need the "comfortable" synchronization API (blocking / timeout), the strict maxsize obeisance or the "Override these methods (_put, _get, ..) to implement other queue organizations" sub-classing behavior, Or when you take care of such things yourself (like in VidGear), then a bare deque is a good and efficient deal for high-speed inter-thread communication.

I see, that explains why it is faster in the I/O bound case than all other implementations. But I am don't understand why it would explain in the CPU bound case it is so much slower here. We have two threads:

Main thread - calling CamGears' .read() method
Slave thread - doing the video reading.

In the benchmark, I emulate CPU bound versus I/O bound cases by getting the main thread (i.e. not the camgears code, but the code that would be the actual software) by calling blocking_call() on the obtained frame from camgears as follows:
def blocking_call(io_limited, duration=0.001):
    """Emulating a time consuming process
    :param float duration: how long to block for
    :param bool is_io_limited: If True, will use time.sleep() to emulate an I/O limited producer.
    If False will use a CPU heavy calculation to emulate a CPU limited producer.
    """
    if io_limited:
        time.sleep(duration)
    else: # cpu bound emulation
        time1 = time.time()
        while True:
            _ = 999*999
            time2 = time.time()
            if (time2-time1) > duration:
                break

In both the I/O limited case and the CPU bound case, we would expect the camgears slave reading-thread to have a full queue and sleep, but that should not affect the FPS I am measuring here - as I am measuring the speed of the main thread at obtaining frames. I would have expected that in both cases, as there is a full queue, the main thread should be able to obtain items from the dequeue near-instantly.
Interestingly, switching out the deque for the Queue in the camgears implementation results in an implementation faster than imutils in both I/O and CPU limited cases, given this should be thread-safe, it seems more robust to different use cases to me. Albeit as you say, the deque implementation does offer a small speed boost in the I/O limited case over a queue (about 2% when I ran it over 3 repeats):
baseline_benchmark: time_for_all_frames: = 2.579 +/- 3.6474 or FPS = 387.638
imutils_benchmark: time_for_all_frames: = 5.396 +/- 0.0261 or FPS = 185.308
camgears_benchmark: time_for_all_frames: = 5.208 +/- 0.0076 or FPS = 191.998
camgears_with_queue_benchmark: time_for_all_frames: = 5.343 +/- 0.0036 or FPS = 187.148

Thanks for your thoughts, interested to understand this one deeply!

switching out the deque for the Queue in the camgears implementation results in implementation about the same speed as the imutils implementation in both I/O and CPU limited cases. Given a queue should be thread-safe, it seems more robust to different use cases to me. Albeit as you say, the deque implementation does seem to offer a small speed boost in the I/O limited case over a queue (about 3% when I ran it over 3 repeats):

@bml1g12 I'll run tests at my end and compare the difference. Actually, when you look into queue.Queue source it just a wrapper around collections.deque. Also deque put() and pop() methods are thread safe and can handle any sized data so these results look vague to me.  Being said that, I'll look other alternatives if deque is throttling, or completely replace multi-threading with something better.

This library looks promising: https://github.com/dmlc/decord

Yeah but you want to wait for #148. A flexible FFmpeg's videocapture gear will be released in upcoming release.

switching out the deque for the Queue in the camgears implementation results in implementation about the same speed as the imutils implementation in both I/O and CPU limited cases. Given a queue should be thread-safe, it seems more robust to different use cases to me. Albeit as you say, the deque implementation does seem to offer a small speed boost in the I/O limited case over a queue (about 3% when I ran it over 3 repeats):

@bml1g12 I'll run tests at my end and compare the difference. Actually, when you look into queue.Queue source it just a wrapper around collections.deque. Also deque put() and pop() methods are thread safe and can handle any sized data so these results look vague to me.  Being said that, I'll look other alternatives if deque is throttling, or completely replace multi-threading with something better.

This library looks promising: https://github.com/dmlc/decord

Yeah but you want to wait for #148. A flexible FFmpeg's videocapture gear will be released in upcoming release.

OK thanks! I agree, it seems odd that deque would be so much slower than queue the latter uses the former. Indeed I think deque should be nice and thread-safe to use.
I haven't got round to documenting the repo yet, but if you are interested in running these locally https://github.com/bml1g12/bechmarking_video_reading_python:
git lfs install
git lfs pull# to get the video file
pip install -e .
python video_reading_benchmarks/main.py

should work run the whole suite of benchmarks.
Results here I have added Decord benchmark with sequential reading, and it was faster than serial but slower than camgears/imutils. It seems from their benchmarks Decord is very fast if one wishes to seek-to random points in the file or do accurate frame-seeking though, so might be better in the use-case of downsampling the video, although I haven't tested that yet.  It also seems like Decord might have some optimised  re-sizing options, which is something I am also benchmarking as I think a common Computer Vision pipeline involves either downsampling or resizing.
https://github.com/abhiTronix/vidgear/issues/148 This looks very interesting! It seems in the OP there that ffmpeg could decode that video at 152 FPS with OpenCV way slower at around 36 FPS. If we could switch to a more direct hook into FFMPEG  it does seem it would offer a huge advantage, as shown in #148 it looks like its about 2X faster than OpenCV. I am also aware that the .set() method in OpenCV is unreliable (https://github.com/opencv/opencv/issues/9053) compared to raw ffmpeg which can do accurate frame seeking, so has that advantage. I am surprised that more direct methods like decode and pyav are so much slower than ffmpeg, but I guess maybe the speed-hit is inevitable as part of converting them to accessible Python numpy arrays.
I am tempted to expand my investigation into comparing the actual decoders too:

PyAV
Decode
And ffmpeg wrappers like https://github.com/kkroening/ffmpeg-python/issues/78

And then try and find the optimal threaded implementation with the optimal decoder.

OK thanks! I agree, it seems odd that deque would be so much slower than queue the latter uses the former. Indeed I think deque should be nice and thread-safe to use.
I haven't got round to documenting the repo yet, but if you are interested in running these locally https://github.com/bml1g12/bechmarking_video_reading_python:
git lfs install
git lfs pull# to get the video file
pip install -e .
python video_reading_benchmarks/main.py

should work run the whole suite of benchmarks.
Results here I have added Decord benchmark with sequential reading, and it was faster than serial but slower than camgears/imutils. It seems from their benchmarks Decord is very fast if one wishes to seek-to random points in the file or do accurate frame-seeking though, so might be better in the use-case of downsampling the video, although I haven't tested that yet.  It also seems like Decord might have some optimised  re-sizing options, which is something I am also benchmarking as I think a common Computer Vision pipeline involves either downsampling or resizing.
https://github.com/abhiTronix/vidgear/issues/148 This looks very interesting! It seems in the OP there that ffmpeg could decode that video at 152 FPS with OpenCV way slower at around 36 FPS. If we could switch to a more direct hook into FFMPEG  it does seem it would offer a huge advantage, as shown in #148 it looks like its about 2X faster than OpenCV. I am also aware that the .set() method in OpenCV is unreliable (https://github.com/opencv/opencv/issues/9053) compared to raw ffmpeg which can do accurate frame seeking, so has that advantage. I am surprised that more direct methods like decode and pyav are so much slower than ffmpeg, but I guess maybe the speed-hit is inevitable as part of converting them to accessible Python numpy arrays.
I am tempted to expand my investigation into comparing the actual decoders too:

PyAV
Decode
And ffmpeg wrappers like https://github.com/kkroening/ffmpeg-python/issues/78

And then try and find the optimal threaded implementation with the optimal decoder.

#148 it looks like its about 2X faster than OpenCV. I am also aware that the .set() method in OpenCV is unreliable (opencv/opencv#9053) compared to raw ffmpeg which can do accurate frame seeking, so has that advantage.

Yeah I saw your comment. That's why I asking to wait for #148.

I am surprised that more direct methods like decode and pyav are so much slower than ffmpeg, but I guess maybe the speed-hit is inevitable as part of converting them to accessible Python numpy arrays.

@bml1g12 That's where vidgear shines. We already have WriteGear's compression mode that provide direct hook into FFmpeg and can be used for high-performance complex tasks like streaming directly to twitch and can even utilize the power of GPU encoding, and you can even flexible run any FFmpeg command. Try those examples, and you'll see.

#148 it looks like its about 2X faster than OpenCV. I am also aware that the .set() method in OpenCV is unreliable (opencv/opencv#9053) compared to raw ffmpeg which can do accurate frame seeking, so has that advantage.

Yeah I saw your comment. That's why I asking to wait for #148.

I am surprised that more direct methods like decode and pyav are so much slower than ffmpeg, but I guess maybe the speed-hit is inevitable as part of converting them to accessible Python numpy arrays.

@bml1g12 That's where vidgear shines. We already have WriteGear's compression mode that provide direct hook into FFmpeg and can be used for high-performance complex tasks like streaming directly to twitch and can even utilize the power of GPU encoding, and you can even flexible run any FFmpeg command. Try those examples, and you'll see.

threaded implementation with the optimal decoder

Believe me that will make it worse. Leave threading, a I have experience way too many bugs while using threading with FFmpeg, its my two cents. OpenCV is robust in this regards.

threaded implementation with the optimal decoder

Believe me that will make it worse. Leave threading, a I have experience way too many bugs while using threading with FFmpeg, its my two cents. OpenCV is robust in this regards.

@bml1g12 So I ran some tests and indeed Pure Threaded implementation (with Queue) was faster than deque. But there's a catch, there were some major cons with Queue:

Queues are faster unless  OpenCV's function cv2.imshow("Output", frame) is used. With this function, Performance drops equally both on deque and Queue and all CPU Cores(mine 4) hits +90% usage.
If quality/resolution of video >= 1080p Hevc, difference is negligible as above.
I cannot use two Python Classes with Queues simultaneously on same machine as it deteriorate performance severely. So CamGear cannot be used with NetGear Class in vidgear, as at the moment both Threads are fired, CPU freezes due to 100% usage on all 4 cores, which wasn't the problem with deques.

So using Queues is double edged sword. It is better in handling processes when CPU has less burden already, but again I don't know what is causing this. Here's a interesting statement from official docs:

collections.deque is an alternative implementation of unbounded queues with fast atomic append() and popleft() operations that do not require locking and also support indexing

@bml1g12 So I ran some tests and indeed Pure Threaded implementation (with Queue) was faster than deque. But there's a catch, there were some major cons with Queue:

Queues are faster unless  OpenCV's function cv2.imshow("Output", frame) is used. With this function, Performance drops equally both on deque and Queue and all CPU Cores(mine 4) hits +90% usage.
If quality/resolution of video >= 1080p Hevc, difference is negligible as above.
I cannot use two Python Classes with Queues simultaneously on same machine as it deteriorate performance severely. So CamGear cannot be used with NetGear Class in vidgear, as at the moment both Threads are fired, CPU freezes due to 100% usage on all 4 cores, which wasn't the problem with deques.

So using Queues is double edged sword. It is better in handling processes when CPU has less burden already, but again I don't know what is causing this. Here's a interesting statement from official docs:

collections.deque is an alternative implementation of unbounded queues with fast atomic append() and popleft() operations that do not require locking and also support indexing

Believe me that will make it worse. Leave threading, I have experience way too many bugs while using threading with FFmpeg, its my two cents. OpenCV is robust in this regards.

I see thanks for the heads up on this.
I have now updated the README of https://github.com/bml1g12/benchmarking_video_reading_python with detailed plots for:
low resolution, medium resolution, high resolution input video
Across all the possible scenarios for the video consumer - an I/O blocked application, a CPU blocked application, and an application that does nothing with the numpy decoded frames (unblocked).

@bml1g12 So I ran some major tests and indeed Pure Threaded implementation (with Queue) was faster than deque. But there's a catch, there were some major cons with Queue:

Queues are faster unless  OpenCV's function cv2.imshow) is used as follows[...]Performance drops equally both on deque and Queue and all CPU Cores(mine 4) hits +90% usage even with 720p videos.

Indeed, the similar performance between queue and deque fits with the results I have found for an I/O limited situations; also in this situation, camgears is the fastest library I can find out there! I think it is a fantastic library, and the goal of VidGears as a whole for vast video manipulation is something that is very valuable to the community.
But the double edgedsword, as you say, is that in the CPU limited case, in my benchmarks and application code, camgears deque comes out as slower than cv2.VideoCapture in isolation, and indeed slower than many other libraries it would seem. I can understand given the requirement to interface with NetGears etc., there are good reasons to keep it as a deque() given the performance it gives in the right situation. But given the danger here of people actually slowing down their code, personally I would suggest adding a little note to the docs warning that in CPU-limited situations CamGears is likely to be slower than raw opencv.
Just to give a little example, In the project I was working on recently, I discovered CamGears was really fast on my local machine and I excitedly switched over my production code to using CamGears. In production, however, the code runs on a machine with less CPU cores available, and after a lot of head scratching and benchmarks, I figured out CamGears was a lot slower than naive opencv/imutils in the CPU-limited case and I ended up switching back. Actually spotting this issue is not obvious for most users I imagine, as they are unlikely to regularly compare video readers in a hardware dependent manner.

Believe me that will make it worse. Leave threading, I have experience way too many bugs while using threading with FFmpeg, its my two cents. OpenCV is robust in this regards.

I see thanks for the heads up on this.
I have now updated the README of https://github.com/bml1g12/benchmarking_video_reading_python with detailed plots for:
low resolution, medium resolution, high resolution input video
Across all the possible scenarios for the video consumer - an I/O blocked application, a CPU blocked application, and an application that does nothing with the numpy decoded frames (unblocked).

@bml1g12 So I ran some major tests and indeed Pure Threaded implementation (with Queue) was faster than deque. But there's a catch, there were some major cons with Queue:

Queues are faster unless  OpenCV's function cv2.imshow) is used as follows[...]Performance drops equally both on deque and Queue and all CPU Cores(mine 4) hits +90% usage even with 720p videos.

Indeed, the similar performance between queue and deque fits with the results I have found for an I/O limited situations; also in this situation, camgears is the fastest library I can find out there! I think it is a fantastic library, and the goal of VidGears as a whole for vast video manipulation is something that is very valuable to the community.
But the double edgedsword, as you say, is that in the CPU limited case, in my benchmarks and application code, camgears deque comes out as slower than cv2.VideoCapture in isolation, and indeed slower than many other libraries it would seem. I can understand given the requirement to interface with NetGears etc., there are good reasons to keep it as a deque() given the performance it gives in the right situation. But given the danger here of people actually slowing down their code, personally I would suggest adding a little note to the docs warning that in CPU-limited situations CamGears is likely to be slower than raw opencv.
Just to give a little example, In the project I was working on recently, I discovered CamGears was really fast on my local machine and I excitedly switched over my production code to using CamGears. In production, however, the code runs on a machine with less CPU cores available, and after a lot of head scratching and benchmarks, I figured out CamGears was a lot slower than naive opencv/imutils in the CPU-limited case and I ended up switching back. Actually spotting this issue is not obvious for most users I imagine, as they are unlikely to regularly compare video readers in a hardware dependent manner.

But the double edgedsword, as you say, is that in the CPU limited case, in my benchmarks and application code, camgears deque comes out as slower than cv2.VideoCapture in isolation, and indeed slower than many other libraries it would seem. I can understand given the requirement to interface with NetGears etc., there are good reasons to keep it as a deque() given the performance it gives in the right situation. But given the danger here of people actually slowing down their code, personally I would suggest adding a little note to the docs warning that in CPU-limited situations CamGears is likely to be slower than raw opencv. Just to give a little example, In the project I was working on recently, I discovered CamGears was really fast on my local machine and I excitedly switched over my production code to using CamGears. In production, however, the code runs on a machine with less CPU cores available, and after a lot of head scratching and benchmarks, I figured out CamGears was a lot slower than naive opencv/imutils in the CPU-limited case and I ended up switching back. Actually spotting this issue is not obvious for most users I imagine, as they are unlikely to regularly compare video readers in a hardware dependent manner.

My idea is move to threading in CamGear only (commit https://github.com/abhiTronix/vidgear/commit/5acb8fbfa1b6d457500a4c4c95358b80b26b5c68 is done) that uses pure-threaded implementation and faster than ever, but still keep using deque in everything else. So now we can enjoy power of both equally. @bml1g12 Can you install this commit for benchmarking as follows:
  # clone the repository and get inside
  git clone https://github.com/abhiTronix/vidgear.git && cd vidgear

  # checkout the latest development branch
  git checkout development

  # install normally
  pip install .

But TBH, I'm more lean towards multiprocessing. But when I experimented, it was too throttling with OpenCV. So problem is back at source not at Process.

But the double edgedsword, as you say, is that in the CPU limited case, in my benchmarks and application code, camgears deque comes out as slower than cv2.VideoCapture in isolation, and indeed slower than many other libraries it would seem. I can understand given the requirement to interface with NetGears etc., there are good reasons to keep it as a deque() given the performance it gives in the right situation. But given the danger here of people actually slowing down their code, personally I would suggest adding a little note to the docs warning that in CPU-limited situations CamGears is likely to be slower than raw opencv. Just to give a little example, In the project I was working on recently, I discovered CamGears was really fast on my local machine and I excitedly switched over my production code to using CamGears. In production, however, the code runs on a machine with less CPU cores available, and after a lot of head scratching and benchmarks, I figured out CamGears was a lot slower than naive opencv/imutils in the CPU-limited case and I ended up switching back. Actually spotting this issue is not obvious for most users I imagine, as they are unlikely to regularly compare video readers in a hardware dependent manner.

My idea is move to threading in CamGear only (commit https://github.com/abhiTronix/vidgear/commit/5acb8fbfa1b6d457500a4c4c95358b80b26b5c68 is done) that uses pure-threaded implementation and faster than ever, but still keep using deque in everything else. So now we can enjoy power of both equally. @bml1g12 Can you install this commit for benchmarking as follows:
  # clone the repository and get inside
  git clone https://github.com/abhiTronix/vidgear.git && cd vidgear

  # checkout the latest development branch
  git checkout development

  # install normally
  pip install .

But TBH, I'm more lean towards multiprocessing. But when I experimented, it was too throttling with OpenCV. So problem is back at source not at Process.

That sounds like a good idea to me; I will replace "camgears_with_queue" on the repo with your official commit when I next get the chance soon.

But TBH, I'm more lean towards multiprocessing. But when I experimented, it was too throttling with OpenCV(I'll introducethat later). So problem is back at source not at Process.

Regarding multiprocessing,  I happen to have been spending a lot of time on related work for that recently. One thing to be aware of that the mp.queue pickles the array, so this is super slow compared to queue.Queue, and so a faster way is to use shared memory; I included an example mulitprocessed implementation in benchmarking_video_reading_python  but it didn't perform that well. I expect it could be optimised, as its effectively currently implemented as queueSize = 1 queue (1 array cached in shared memory at a time). In a different project I tried a more fancy implementation but didn't manage to get a speed boost.

That sounds like a good idea to me; I will replace "camgears_with_queue" on the repo with your official commit when I next get the chance soon.

But TBH, I'm more lean towards multiprocessing. But when I experimented, it was too throttling with OpenCV(I'll introducethat later). So problem is back at source not at Process.

Regarding multiprocessing,  I happen to have been spending a lot of time on related work for that recently. One thing to be aware of that the mp.queue pickles the array, so this is super slow compared to queue.Queue, and so a faster way is to use shared memory; I included an example mulitprocessed implementation in benchmarking_video_reading_python  but it didn't perform that well. I expect it could be optimised, as its effectively currently implemented as queueSize = 1 queue (1 array cached in shared memory at a time). In a different project I tried a more fancy implementation but didn't manage to get a speed boost.

I've added the result of the commit you made here https://github.com/abhiTronix/vidgear/pull/192 and suggested a small change to improve its performance

I've added the result of the commit you made here https://github.com/abhiTronix/vidgear/pull/192 and suggested a small change to improve its performance

@bml1g12 Merged.

@bml1g12 Merged.

@bml1g12 Little suggestion here. Your Graphical Plots looks a bit improper due to time(per thousand frames) vs libraries with FPS as hue format that leads to low FPS has large bar height but high FPS has almost negligible bar height. But instead you should using FPS vs libraries with time(per thousand frames) as hue. Also you should cap FPS to maximum value to 1000 fps, so it will look more presentable.

@bml1g12 Little suggestion here. Your Graphical Plots looks a bit improper due to time(per thousand frames) vs libraries with FPS as hue format that leads to low FPS has large bar height but high FPS has almost negligible bar height. But instead you should using FPS vs libraries with time(per thousand frames) as hue. Also you should cap FPS to maximum value to 1000 fps, so it will look more presentable.

Its something I have gone back and forth over in my head a few times; FPS would be far more elegant and intuitive metric, but the thing is in some cases the error bars will become quite large (when the absolute time becomes quite small), so really want to get error bars in there, but the error bar of FPS is asymmetric (as its 1/error) and its not easy (as far as I can see, almost not possible) to plot assmetric error bars on a bar plot in seaborn; so would need to switch plotting library to keep sensible error bars

Its something I have gone back and forth over in my head a few times; FPS would be far more elegant and intuitive metric, but the thing is in some cases the error bars will become quite large (when the absolute time becomes quite small), so really want to get error bars in there, but the error bar of FPS is asymmetric (as its 1/error) and its not easy (as far as I can see, almost not possible) to plot assmetric error bars on a bar plot in seaborn; so would need to switch plotting library to keep sensible error bars


Can't read tables!

I get current database and user but i can't enumerate the 182 tables...
Maybe firewall ? Any solution?

I have the same thing

yes it could be a firewall you can proxy the traffic through burp to see whats going on and try manually, this response is intended when Ghauri find some sort of blockage during payloads it says this.


Proxy crashes at connecting to the device (iOS 8.4)

NULL SystemBUID is returned here so the next line crashes with access violation.
The version bundled with Valence crashes as well.
No crash occurs with the same device on latest Linux version (though it does not work anyway due to https://github.com/google/ios-webkit-debug-proxy/issues/82).

thanks for the report, I'll look into the issue

@DarkDaskin I guess it should be fixed with the latest libimobiledevice, check out this build


Make ready for initial public release

Flesh out API design and get it ready for review
Decide on initial milestone and implement required items

completed


Cleanup deps

[x] remove unused dependencies
[x] update some dependencies
[x] make sure godep works again

@dmp42 Is it fixed?

We may want to update some of our deps.
Wdyt?

@dgageot specifically worth investigating this warning: code.google.com is shutting down; import path code.google.com/p/goauth2/compute/serviceaccount will stop working

Closed with https://github.com/docker/machine/pull/2391, https://github.com/docker/machine/pull/2394 and https://github.com/docker/machine/pull/2399


I want to add a apply and cancel button in it. how it is possible?

Subject of the issue
I want to add a apply and cancel button in date range picker. how it is possible?

Hi @Tariqali13 , you can embed <DateRangePicker in your own component that keeps the date changes in its state and handles the apply/cancel actions.

Cancel button would just hide the range picker.
Apply button would trigger a function to handle the current selection

Also, for the cancel button to work nicely, you would need to save the initial selection so, if a user hits Cancel, you would restore your calendar selection to prior values.
I hope this helps. I'm planning to work on documentation that would explain scenarios like this one.

@nerychucuy please provide the documentation for achieving this easily.

Hi. @nerychucuy  thanks for the response, but i have already achieve this approach. it's will be good if it is provided by default.


[FEATURE] granular lookahead control at path level

Controlling the segments lookahead via the CLI is great,
But would be even nicer overriding it via the OpenAPI definition file for specific paths.
e.g. x-nodegen-lookahead

Currently this feature was removed.. needs addressing

This is now resolved with  https://acrontum.github.io/generate-it/#/_pages/features?id=nested-stub-files-aka-nested-domains


Consistent ordering of counts, celda.mod for downstream functions

Many downstream plotting and analysis functions take in as the first two arguments 'counts' and 'celda.mod'. However the order of these two vary from function to function. Let's do 'counts' and then 'celda.mod'.

We took care of this in #297 and #308


[Features] Reintroduce sub-du

Resolves https://github.com/paritytech/substrate/issues/12409
At the moment this is just a copy-paste with updated dependencies.

[ ] follow-up with devops: wrap this in a simple HTTP server application (external repo), deploy it on state.polkadot.network or something like that.

So this loops through the pallet+storage items and calculates their keys?
I wonder how many keys the first approach missed. There are special keys likes :CODE: which would not be included.
Maybe looping through the trie keys and doing a best-effort reverse lookup could find them.

I wonder how many keys the first approach missed. There are special keys likes :CODE: which would not be included.
Maybe looping through the trie keys and doing a best-effort reverse lookup could find them.

This only looks at the storage items that are in the metadata, so yeah any custom key is missed, and probably fine. Exposing well_known_keys over metadata seems totally reasonable. Although it won't really fix the problem.

bot rebase

wrap this in a simple HTTP server application (external repo), deploy it on state.polkadot.network or something like that.

 Just as a community utility thing?

 Just as a community utility thing?

Yeah, just a remote api that would conveniently show latest storage of a given network. Possibly with some sort of dumb cache to make sure multiple requests within a short period of time are handled without issues.

bot rebase

bot rebase

Last time I tried it it would not connect because of some RPC error.
Did you try it yet @ruseinov ?

Last time I tried it it would not connect because of some RPC error. Did you try it yet @ruseinov ?

Not yet, getting to it now

@kianenigma I have removed sub-storage.
In the current implementation I am using wrappers done in remote-externalities builder to achieve faster results. Once all of this works - we can discuss having those helpers someplace else shared by the two.
But actually making a few methods public might not hurt remote-externalities much.
This is still a WIP, any suggestions welcome.

In the current implementation I am using wrappers done in remote-externalities builder to achieve faster results.

This is not really correct. All you need is:

an RPC call to get state_getMetadata
an RPC call to get state_storageSize (or similar)

Both of which are provided neatly by substrate RPC utilities. None of these are related to remote-ext specifically.

@niklasad1 it might not be bad idea if you entirely take this over, as Roman is busy with other stuff (that's way more high priority).

@niklasad1 it might not be bad idea if you entirely take this over, as Roman is busy with other stuff (that's way more high priority).

Yeah, not possible for me to proceed with this atm. But I'll get back to this if it's not done by the time I'm finished with the other stuff.

@harrysolovay would the idea behind this be a good tool to build with CAPI?


Variables created by extract are not recognized

Larastan Version: 2.6.4
--level used: 5
Pull request with failing test:

Description
Hello!
When receiving an array in a method I am applying extract($data), larastan tells me that the variables contained in the array may not be defined, which is not the case.
Errores!
308    Variable $variable1 might not be defined.
308    Variable $variable2 might not be defined.
308    Variable $variable3 might not be defined.
308    Variable $variable4 might not be defined.
308    Variable $variable5 might not be defined.

Laravel code where the issue was found
public function create(array $data)
    {
        extract($data);
        ..... // remaining logic of the function
    }

Thanks!

Wow, it would be wonderful if you didn't have to live without extracts, .neon becomes super big

extract is not your friend. That is all.
The PHP language has bad parts.

Hi,
This is not related to Larastan. Please report it to PHPStan. But first try to replicate the error on https://phpstan.org/try


4DU3

Use the preview tab to see the example given below. Edit the relevant information and preview the changes before submitting. You may delete these instructions.

Key
Value

ID
4DU3

Source
Vaaran Bhai Gurdas Ji

Page
28

Line
gur isKI dw isKxw; nwdu n vyd n AwiK vKwxY [

Correction
THIS ≠ THAT

PROOF (EDITION)
Image:

Duplicate #577


New UI

Hey Adrian!
Here's a new UI i made for your app. Sent you a message on Facebook to know your thought on making a new UI, but i got no response. I hope it's worthy of your merge.
Thank you!

hi @dev-charles15531, i changed base branch that merge will go into - sorry for inconvenience, but could you please check and try to resolve those bugs?

Alright, i wi.

Hello @xEdziu
All conflicts have been resolved


Double entries in stereotype export

There are SAF_SCV02a_View and SAF_SCV02b_View entries available in the CSV export of the stereotypes. In my opinion SAF_SCV02b_View should be deleted as a entry. (see "stereotypes.csv" https://github.com/GfSE/SAF-Specification/blob/main/stereotypes.csv)

this is a problem caused by the markdown generator, it did not write the documentation of the grid viewpoint into that stereotype SAF_SCV02b_View.
( because the generator doesnt handle the case when a stereotype implements both a viewpoint and concepts)
Since the Grid Viewpoint is in the state "proposed" please just ignore the SAF_SCV02b_View stereotype.

documentation and generator fixed, stereotype stays.


⚠ ClamAV has degraded performance

In bb78f15, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 240 ms

Resolved: ClamAV performance has improved in 9f5846c.


How can we add "staked DFI" at Lock to the total balance of the users ? Maybe as a specific asset? (Not decided yet)

Maybe indicate the staked amount in a different way. Having it in the list of tokens implies that it's a (staked) token that can be sent, traded, etc. I would suggest we imitate the behavior of bank apps that show available balance and reserved balance separately.


Message defaults

The more I use this bundle, the more I think that the defaults should be set to null, rather than true or false.
This way it takes on the account defaults, and the user can override as needed.

+1

Guys, can you please review
https://github.com/Hipaway-Travel/HipMandrillBundle/tree/message-defaults-set-null
let me know if this serves your needs. Please also note any bugs with this branch.
Thx. Sven

ok I had some time to test it, should be fine now. If you find any bugs let me know or issue a PR. thx.


@JuliaRegistrator register() v5.0.2

@JuliaRegistrator register()

Registration pull request created: nkottary/General/26
Optionally, you can create a tag and release on this repository for the above registration.


Improve metadata validation

also little build fix: pin dependencies

:white_check_mark: Build plexus-interop 718 completed (commit https://github.com/finos/plexus-interop/commit/8e87062bcb by @iskender-kamchibekov-db)


[BUG] app-template-svelte-typescript fails to compile App.svelte if unrelated test import is removed

Bug Report Quick Checklist

[x] I am on the latest version of Snowpack & all plugins.
[x] I use package manager npm
[x] I run Snowpack on OS Windows 10
[x] I run Snowpack on Node.js v14

Describe the bug
I've come across a problem where the application code no longer compiles when a test library import is removed from a seemingly unrelated file.
To Reproduce
From https://github.com/snowpackjs/snowpack/discussions/2472:
# Create project with the template
npx create-snowpack-app theapp --template @snowpack/app-template-svelte-typescript

# Enter the project
cd theapp

# Verify that the project works
npm start # This succeeds

# Remove the test file
rm src/App.test.ts

# Now the project fails to build citing an unrelated file not being found
npm start

In this example I've removed the entire file, but it is enough to remove or comment out just this line:
https://github.com/snowpackjs/snowpack/blob/0f9d34b8cf747e33524b31920d5610f6403c5480/create-snowpack-app/app-template-svelte/src/App.test.js#L1
Expected behavior
It should work.
Anything else?
@thisislawatts found a solution: https://github.com/snowpackjs/snowpack/discussions/2472#discussioncomment-439012
@lpil suggested:

it looks like we may need to add the npm i --save-dev @tsconfig/svelte dep and add "extends"<EMAIL_ADDRESS>to .tsconfig.json for that template.

After adding @tsconfig/svelte now I have another error in my index.ts file:
Property 'hot' does not exist on type 'ImportMeta'.ts(2339).
😭

This has been fixed in the latest patch of @snowpack/app-template-svelte-typescript! Thanks for opening

Thank you!


FR: is there a web version available?

Hey @wpcarro ,
Thanks for your question! If by web version you mean a UI with which one can specify a PrometheusURL and then display checks, no there is not.
However, there is an exporter mode that delivers Prometheus metrics, this is also done via web (/metrics endpont).

Closing this issue now, hope I answered your question 🙇♂