[Feature] publish extension to Firefox adds-on too

Hi there,
A maximum number of users use chrome browser but firefox is also used by a huge number of people. I think extension should also be available in firefox adds.
This can help to have perceptor options in GitHub through the firefox browser too.

The release of Firefox version is not in current plan.
If anyone can make a survey, we may consider it.

Hi @LiuChangFreeman I understand about it. Should I disclose this issue as currently none of the maintainers might take it for the current plan?

Hi @LiuChangFreeman I understand about it. Should I disclose this issue as currently none of the maintainers might take it for the current plan?
At your will.


Assignment to readonly property error.

Following the installation guide:

Download zip.
Install cocoapods.

Build failed with several errors:
leanchat-ios-master/LeanChatLib/Classes/controllers/CDChatRoomVC.m:437:27: Assignment to readonly property
leanchat-ios-master/LeanChatLib/Classes/controllers/CDChatRoomVC.m:441:30: Assignment to readonly property
leanchat-ios-master/LeanChatLib/Classes/controllers/CDChatRoomVC.m:442:36: Assignment to readonly property
leanchat-ios-master/LeanChatLib/Classes/controllers/CDChatRoomVC.m:463:16: Assignment to readonly property
leanchat-ios-master/LeanChatLib/Classes/controllers/CDChatRoomVC.m:512:33: Assignment to readonly property
leanchat-ios-master/LeanChatLib/Classes/controllers/CDChatRoomVC.m:585:24: Assignment to readonly property

Thanks for your help.

Hey, thanks for your feedback! Nailed it already.

Thanks @wrshi ,I've checked https://github.com/leancloud/leanchat-ios/commit/2eda7be10124bea9f7fd97e70835e613dfa18329 ,but is it ok that just deleting the code?
If you just delete the code there, then how will it work properly while storing failed messages or changing resending status?

Relax :) all the readonly properties will be set and updated automatically in the sdk, you don't need to worry about it now.

Cool. Thanks!

My pleasure :)


Fix issue #1

Dropped parsing indexes from places and transitions names.
Names are kept now and indexes are generated automatically.
Added tests for custom names and consecutive indexes

This change is

src/Petri/PNMLreader.java, line 119 at r1 (raw file):

	/**
	 * Parses a list of nodes and returns information about places, transitions and arcs embedded

We could add a documentation about the sort of places here.

Comments from Reviewable

src/Petri/PNMLreader.java, line 172 at r1 (raw file):

	private Place getPlace(String id, Node placeNode, NodeList nl) throws BadPNMLFormatException{
		Integer m_inicial = 0;
		Integer placeIndex = this.placesIndex++;

I think that the places index should increment only if the place don't have a name.
i.e: I have 5 places with the follow names:
placeExample1
noName
placeExample2
noName
placeExample3
"noName" places should have index 1 and 2 respectively, and not index 2 and 4.

Comments from Reviewable

src/Petri/PNMLreader.java, line 209 at r1 (raw file):

		Label label = null;
		Pair<String, Boolean> guard = null;
		Integer transitionIndex = this.transitionsIndex++;

The same comment in Places

Comments from Reviewable

Reviewed 9 of 9 files at r1.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

Comments from Reviewable

Review status: all files reviewed at latest revision, 3 unresolved discussions.

src/Petri/PNMLreader.java, line 119 at r1 (raw file):
Previously, mauriludemann wrote…
> We could add a documentation about the sort of places here.

I don't see that need here

src/Petri/PNMLreader.java, line 172 at r1 (raw file):
Previously, mauriludemann wrote…
> I think that the places index should increment only if the place don't have a name.
> i.e: I have 5 places with the follow names:
> placeExample1
> noName
> placeExample2
> noName
> placeExample3
> "noName" places should have index 1 and 2 respectively, and not index 2 and 4.

Doesn't apply

src/Petri/PNMLreader.java, line 209 at r1 (raw file):
Previously, mauriludemann wrote…
> The same comment in Places

ditto

Comments from Reviewable


Updated the Note section.

CustomKubeletConfig is not supported for windows OS.  Submitted feedback - https://feedback.azure.com/d365community/idea/659a481b-ee22-ed11-a81b-6045bd7c715d
Raised a ticket #2208220040008378 and ETA for the feature is not released yet.

@palma21

Can you review this PR?

IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Hi @asudbring - Can you review this old PR and determine whether it needs to be closed or merged?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.

#sign-off


⚠ Secret Website 3 has degraded performance

In cbcd98d, Secret Website 3 ($SECRET_WEBSITE_3) experienced degraded performance:

HTTP code: 200
Response time: 2958 ms

Resolved: Secret Website 3 performance has improved in 20982dd.


AFP_LOGIN and AFP_PASSWORD not quite working?

Just updated to b93ac2782ded (have been stable for forever) and my Macs couldn't connect to the AFP volume.  I tried a few restart/rebuilds of the image, same issue.
My docker-compose environment looks like this (and has looked like this for a year+):
    environment:
     - AFP_LOGIN=tm
     - AFP_PASSWORD=some_passsword
     - AFP_NAME=TimeMachine
     - AFP_SIZE_LIMIT=700000

I was able to fix my issue by running add-account:
$ docker exec 5eab255ef4ee add-account tm some_password TimeMachine /timemachine
chpasswd: password for 'tm' changed

After that I am able to connect via AFP normally.  So, it seems like the default single user setup using AFP envs might be broken in some way in a recent change.

Found my issue, needed to set PUID and PGID for the AFP* variables to work right.


[WIP] Switch to mdast, use inline styles everywhere

An experiment to see if we can tweak the Markdown renderer to apply inline styles. I thought this could solve #71 #73 and #75, and clean up the styling code but I hit some complexities in how much we can customize without basically forking mdast-react.
The main problem is nested elements. Without transforming the AST, nodes are not aware of their parent. And if we want to use inline styles all the way down, for example paragraphs need to know if they're nested inside a blockquote or listItem. And even if we modify the children to be aware of their nesting, I couldn't figure out a straight-forward way to play nice with mdast-react which allows customization of the components used for rendering but only after the AST information is lost.
Turns out, recreating a CSS rule like blockquote > p with inline styles is surprisingly difficult :sweat_smile:
:warning: :skull: DO NOT MERGE :skull: :warning:

I'm still considering migrating to another Markdown parser but at the moment there's no urgent need. BTW mdast is now remark with supposedly better plugin support but let's revisit this topic at a later point.


Change implementation owner to address(1) from address(0)

This Code4rena finding correctly points out that the implementation being owned by address(0) might expose attack surface area. Though we cannot find a way to exploit this currently, it's trivial to change the implementations owner to address(1) to completely eliminate this vector.

Closing out -- SignatureCheckerLib.isValidSignatureNow appropriately returns false for address(0):
                    // `returndatasize()` will be `0x20` upon success, and `0x00` otherwise.
                    if iszero(or(iszero(returndatasize()), xor(signer, mload(t)))) {
                        isValid := 1
                        mstore(0x60, 0) // Restore the zero slot.
                        mstore(0x40, m) // Restore the free memory pointer.
                        break
                    }

Unit test


CMake on Windows fails with: "install Library TARGETS given no DESTINATION!"

How to reproduce -
git clone https://github.com/Intel-Media-SDK/MediaSDK
cd MediaSDK
cmake -H. -Bbuild
cmake version 3.12.3, on WIndows 10.
Stack overflow answer:
https://stackoverflow.com/questions/14990343/cmake-error-targets-given-no-library-destination-for-shared-library-target

As of now this version of mediasdk supports only Linux. It is not intended to be buildable on Windows. This is reflected in the readme https://github.com/Intel-Media-SDK/MediaSDK#system-requirements: "Operating System: Linux"

Hi @bezalified i'm going to close the issue, because currently we don't have plan to enable this


ModuleNotFoundError: No module named 'engineio'

Running main.py gives the error:
Traceback (most recent call last):
File "/content/Voice-Cloning-App/main.py", line 5, in <module>
from engineio.async_drivers import threading  # noqa
ModuleNotFoundError: No module named 'engineio'
Running pip list shows that python-engineio is installed
p.s. I am running this in google colab

I believe you have to use python 3.6 for it to work, untill mister ben updates the requirements, and more importantly fix my dll error


Discovery for ECS

In an earlier evaluation, ECS discovery was rejected due to API rate limiting issues described at the discovery section.  As of today, there are ECS users that are publishing Prometheus metrics and using CloudWatch Agent's Prometheus scraping capabilities. They configure the agent with task selection mechanism to shard the load among multiple clusters. Influenced by what the users already do, we think we can tackle the problem in a couple of ways:

Asking users to configure the discovery to discover a set of matching tasks from a cluster, cache metadata in memory where possible.
Querying the initial data with the ECS API and then relying on ECS events to identify new and terminated tasks.
Asking users to run Prometheus as a sidecar in their ECS tasks as a last resort.

Given we have this functionality in the CW Agent, not having a similar capability in Prometheus is confusing the ECS users. We would like to fill this gap by contributing an ECS discovery agent to Prometheus and want to switch to the discovery mechanism provided here in all our other collection agents (CW Agent, OpenTelemetry Prometheus Receiver, etc)
Goals

Discovery will only discover metric endpoints from a single cluster.
We will allow users to filter the tasks by the Cluster Query language and ECS tags.
Users should be able to specify ports and metrics path where the Prometheus metrics are published from the task. (See the config for more.)
ECS discovery will support both ECS on EC2 and ECS on Fargate.

Config
Once implemented, ECS discovery will be supported in the Prometheus config. The example below will query the cluster to discover ECS tasks/containers matching the given task selectors.
scrape_configs:
  - job_name: ecs-job
    [ metrics_path: <string> ]
    ecs_sd_configs:
      - [ refresh_interval: <string> | default = 720s ]
        [ region: <string> ]
        cluster: <string>
        [ access_key: <string> ]
        [ secret_key: <secret> ]
        [ profile: <string> ]
        [ role_arn: <string> ]
        ports:
            - <int>
        task_selectors:
          - [ service: <string> ]
            [ family: <string> ]
            [ revisions: <int> ]
            [ launch_type: <string> ]
            [ query: <string> ]
            [ tags:
               - <string>:  <string> ]

Discovery
Discovery is done by periodically pulling the ListTasks API. Discovery will only return the ACTIVE tasks.
As an improvement, we will switch to a model where we will listen to ECS events to be notified about the task start and terminations in the future. This will allow us to call the ListTasks for once and rely on the events for the changes as an optimization.
Labels
Prometheus discovery can automatically add ECS task/container labels to the scraped metrics. The discovery will add the following labels:

Label
Source
Type
Description

__meta_ecs_cluster
ECS Cluster
string
ECS cluster name.

__meta_ecs_task_launch_type
ECS Task
string
"ec2" or "fargate".

__meta_ecs_task_family
ECS Task
string
ECS task family.

__meta_ecs_task_family_revision
ECS Task
string
ECS task family revision.

__meta_ecs_task_az
ECS Task
string
Availability zone

__meta_ecs_ec2_instance_id
EC2
string
EC2 instance id for EC2 launch type. Otherwise "fargate".

Authentication & IAM
We will use the default credential provider chain, the following permissions are required:

ec2:DescribeInstances
ecs:ListTasks
ecs:DescribeContainerInstances
ecs:DescribeTasks

Thank you for this proposal.
Overall the proposal is interesting and I recognize the need to have this additional AWS integration. I have a few comments/questions, just by reading your proposal. I am currently not familiar with ECS, so I have a few questions.
Is there any additional metadata? The fact that you use tags to filter the targets means that we can probably expose the tags as additional metadata.

We will use the default credential provider chain.

Is is the same thing we use for EC2/Lightsail/Sigv4 ? Or should we all align them to this new technique as an intermediate step? (we'll have to be careful and be backwards compatible).

port_path

port_path as explained here might be confusing. Prometheus is generally explicit in its configuration. Could we have:
- port: <int> | default 80
  metrics_path: <string> | default /metrics

It's unsure why we would use port 9090 by default, should we simply ask the user to set at least one port? Is there a way to also filter the ports by a portName?
I'd note that metrics_path is probably not really useful here since it can be set at the scrape_config level and via relabeling.
It is also unclear to me why port_path is a list. Do you plan to verify it against the exposed ports of the containers or add it anyway for every target?
You also plan to filter on ACTIVE tasks. Does this state also cover the containers that are starting and terminating?

The proposal didn't have too much detail but additional metadata could be the EC2 instance metadata that runs the containers. It requires an additional request to get details of an EC2 instance for every ECS task container and instance metadata can be useful to identify the internal and external IP addresses of the task. These IPs don't change until the task is killed, so we can cache them in memory rather having to query them again and again.

Is is the same thing we use for EC2/Lightsail/Sigv4 ? Or should we all align them to this new technique as an intermediate step? (we'll have to be careful and be backwards compatible).

This is what they use, nothing new here. It's the standard best practice and mechanism to do auth.

port_path as explained here might be confusing. Prometheus is generally explicit in its configuration. Could we have:

I wanted this to allow containers to publish at paths they would prefer but I have no objections to your suggested and my initial version included a port and a metrics_path just like yours.

It's unsure why we would use port 9090 by default, should we simply ask the user to set at least one port? Is there a way to also filter the ports by a portName?

Good question, 9090 came from the sidecar I'm writing that will publish ECS infra metrics in the Prometheus format but it's not a good port to default to. Ports don't have names so it's not possible to query ports by name. I think I overoptimized this for the sidecar and expecting users to set at least one port sounds reasonable.

I'd note that metrics_path is probably not really useful here since it can be set at the scrape_config level and via relabeling.

I agree, let me move them to the ecs_sd_configs level.

You also plan to filter on ACTIVE tasks. Does this state also cover the containers that are starting and terminating?

This means starting and terminating tasks won't be discovered. Starting tasks will only be discovered at the next discovery if they started by the time we are querying the tasks again.

I updated the configuration in the original proposal. I also turned the port into an int array because a task contains multiple containers that may publish multiple metric handlers.

We know some users use one prometheus with multiple AWS accounts. Is it planned to have the current EC2's auth parameters?
# The AWS API keys. If blank, the environment variables `AWS_ACCESS_KEY_ID`
# and `AWS_SECRET_ACCESS_KEY` are used.
[ access_key: <string> ]
[ secret_key: <secret> ]
# Named AWS profile used to connect to the API.
[ profile: <string> ]

# AWS Role ARN, an alternative to using AWS API keys.
[ role_arn: <string> ]

Given than metrics_path is no longer per port, it would be easier to just keep them at the scrape_configs level and not repeat it at the service discovery level.

Updated the config to add the auth and removed the metrics_path. Not sure if I got the notation correctly, I'm not very familiar with it.

prometheus_scrape: "true" should probably be string: string, otherwise LGTM.

Updated the labels to be aligned with what we are doing for the ECS exporter, https://github.com/prometheus-community/ecs_exporter/pull/2.

My experience has been with a fork of github.com/teralytics/prometheus-ecs-discovery which is working well. We added ratelimiting of AWS API calls and a cache of task definitions between discovery runs which has pretty much solved problems with hitting API ratelimits. We run one prometheus instance per AWS region per account and it manages to discover and scrape from a large number of clusters, tasks and containers.
I'm working on getting the changes we made cleared for contribution back to the original project which may be helpful to inform this design?

Hello, We have the same need, I'm thinking of going to https://github.com/teralytics/prometheus-ecs-discovery for the moment, but I would have liked native support, do you have more information on the progress of this feature?
Thank You

We've been considering a few options how we can support this on ECS more natively so the autodiscovery problem becomes a non-problem. If existing solutions are sufficient for now, I'd highly recommend using them. I'll update the proposal once we have something more concrete.

is anyone using any updated forks for the prometheus-ecs-discovery project? or any idea if we are to see an ecs_sd_configs anytine soon? asking this as I've seen recently in the operator that we have the equivalent for ec2

Hello from the Prometheus bug-scrub!
As far as I can see, there was no code proposed for this implementation.
Amongst the current Prometheus maintainers I don't think anyone is actively using ECS.
Now that we have http SD, I would suggest that anyone who is interested builds an adaptor for ECS that way.
It could be based on https://github.com/teralytics/prometheus-ecs-discovery.


Adding open/read timeout as options.

Added open/read timeout as an options so we can pass them into the Net::HTTP client.

I think your pull request miss some extra values
extras[:open_timeout] and extras[:read_timeout]
They should be define by default right ?

Half minded adding it, but thought the mileage may vary. Would like to know what you think!

well I have no idea :)


Adding eu-west-1 region to defaults

Adding defaults for EMEA region into the provisioner, confirmed working for recent lightbulb sessions.

Thanks @smapjb. We need to work on making the provisioner support all regions and other cloud providers without PRs like these, but in the meanwhile this is appreciated.
We need to document support of this region. I will do that in another PR rather than hold this one up.


settings.html

https://tableau.github.io/extensions-api/docs/interfaces/settings.html 404's

Fixed in dev, coming in tomorrow's release.


ADS-B out

Stratux version: 1.4r4

Stratux config:
SDR

[ ] single
[x] dual

GPS

[x] yes
[ ] no
type: Adafruit GPS

AHRS

[ ] yes
[x] no

power source: Battery pack
usb cable:

EFB app and version: Skydemon 3.9.1
EFB platform: Android 6.0.1
EFB hardware: Sony Xperia Z3

Description of your issue:

Is it possible to add additional hardware or modify the software to provide ADS-B out? In essence I want to try to make a whole package that includes a transponder.

If you are thinking of a portable device, FAA unlikely to approve it. For installed ADS-B OUT, it would need to meet regulatory specs and requirements.

Stale issue, closing.


vsc unexpected close when open menu File -> Open Recent

When I only open menu (by mouse) File -> Open Recent, all available VSC is close without any notifications or errors.
Here is my VSC version:

It seems resolve when I just update to new VSC version:


Fire event when core config is updated

Description:

Fire event when core config is updated
Support updating core config
Store core config in update

This is a follow-up to #23872
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

If the code does not interact with devices:

[x] Tests have been added to verify that the new code works.

Build failed on dev https://circleci.com/gh/home-assistant/home-assistant/26896?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification

@awarecan Yes i saw that, but it seems unrelated to this PR?


Dispose of FtpDataStream Now Reads Control Reply

This resolves issue #167.
The change here was to move all of the clean-up functionality to the Dispose(bool) overrides and simply use the Close() methods to call Dispose().
As FtpDataStream.Dispose(bool) handles the reply from the control connection, we store this in a field so it may be returned from the shadowing FtpDataStream.Close() method.

Thank you for this! I have been unable to fix this for a while...

This was a bad idea. Reverting.

Bad idea. We should not change the API since lots of projects have already followed this pattern: OpenRead() and GetReply(). If you call GetReply() internally, there will be an extra call to GetReply() and it will hang on the 2nd call. All existing projects will break.

Is this not something which could be kept perhaps for the next major release and marked as a breaking change in the release notes?
If people are manually calling things such as GetReply it indicates the API surface is too large and should be reduced.


[Error]: Content-Length header already present

Preflight Checklist

[X] I agree to follow the Code of Conduct that this project adheres to.
[X] I have searched the issue tracker for an issue that matches the one I want to file, without success.
[X] I am not looking for support or already pursued the available support channels without success.

Version
1.9.3
Installation Type
Official SaaS Service
Describe the details of the bug and the steps to reproduce it
JDK 1.
项目中某些接口在访问的时候会报出Content-Length header already present的错误
Additional Information
No response
Logs
Caused by: io.dongtai.iast.thirdparty.org.apache.http.ProtocolException: Content-Length header already present
	at io.dongtai.iast.thirdparty.org.apache.http.protocol.RequestContent.process(RequestContent.java:97)
	at io.dongtai.iast.thirdparty.org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttpProcessor.java:133)
	at io.dongtai.iast.thirdparty.org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
	at io.dongtai.iast.thirdparty.org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
	at io.dongtai.iast.thirdparty.org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)

Can you provide a more complete exception stacktrace


Create Readme.md For Project

Projects Details and what we want to achieve in this gaming review site.

Completed


[CT-3469] [Feature] Model Inheritance / Partial Contracts

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
I would like to see a concept of inheritance when defining contracted models. A contracted model could utilize partial table definitions for similar models and enforce constraints that apply to columns in that superclass. Example:
partials.yaml
partial_models:
- name: some_partial
  columns:
  - name: id
    data_type: int
    constraints:
    - type: primary_key
  - name: fiscal_year
    data_type: int
    constraints:
    - type: check
      expr: fiscal_year between 1980 and 2100

And then a model could inherit this partial like so:
some_model.yaml
models:
- name: some_model
  config:
    contract:
      enforced: true
      inherits:
      - some_partial
  columns:
  - ...Additional columns

Here, the some_model table would minimally need to have an id column that is unique and not null AND a fiscal_year column in which the values are in the range [1980, 2100].
Describe alternatives you've considered
There might be limited ability to do something like this in the dbt_project.yml file - I can't say for sure. If it is possible, the amount of configuration would be pretty large for non-trivial applications.
Who will this benefit?
This feature would be very useful for projects that contain models that share a similar structure. By factoring out repetitive contract patterns, this feature would result in a smaller, DRY-er codebase. Additionally, these partial definitions can offer a higher-level semantic description of the contracts that are enforced on the models.
Are you interested in contributing this feature?
No response
Anything else?
The closest analog to these partials would be an Abstract Base Class, which cannot be directly materialized, but whose definitions can be inherited.
I imagine that model yaml configs would "merge" with the configs of the interfaces it inherits, with an order of precedence going something like:

config blocks in SQL files
model yaml configs
inherited configs
dbt_project.yml configs

So, for instance, one could add/overwrite descriptions to the fields in the model yaml.

Hi @serene-capybara thanks for opening!
The goal of model contracts is to be explicit - we actually think it's best to define the full list of column names and data types for a given contract. Given that goal, I don't think we would enable something like "partial contracts".
However, I completely understand that's a lot of yml to write! I would recommend you check out either:

dbt-codegen generate_model_yaml macro (using the include_data_types argument)
dbt-meshify operation add-contract command

to help you generate this yml faster.


fixed delete-image error code

Description
when trying to delete an image with status "SUCCESS", the rc should be 400
Fixes # (issue)
THEEDGE-2863
Type of change
What is it?

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update
[ ] Refactor

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I run make pre-commit to check fmt/vet/lint/test-no-fdo

Codecov Report
Base: 38.10% // Head: 38.13% // Increases project coverage by +0.03% :tada:

Coverage data is based on head (e3107a7) compared to base (e24bb71).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1684      +/-   ##
==========================================
+ Coverage   38.10%   38.13%   +0.03%
==========================================
  Files          68       68
  Lines        9448     9448
==========================================
+ Hits         3600     3603       +3
+ Misses       5418     5416       -2
+ Partials      430      429       -1

Impacted Files
Coverage Δ

pkg/routes/images.go
28.18% <100.00%> (ø)

pkg/services/devices.go
50.43% <0.00%> (+0.32%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

LGTM


chore: create a canary release in NPM for each commit merged in master

The canary version use the commit sha1 like: 1.2.0-canary.{sha1}

Pull Request Test Coverage Report for Build 2641

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 80.479%

Totals

Change from base Build 2634:
0.0%

Covered Lines:
2578

Relevant Lines:
3094

💛  - Coveralls


handshake query

Handshake query data has been moved from query to _query for some reason.
EDIT this is a server-side issue, sorry. I'll delete this myself if I can work out how.

It's preferred to parse any needed url components from socket.request.


Enum refactoring

Feature or Bugfix

Refactoring

Detail

Get rid of redefinitions of the same Enums. Used class GraphQLEnumMapper where it's required
Unhardcoded enum-constants for migrations and tests

Security N/A
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Hi @SofiaSazonova @dlpzx - what is left to be done before we can push forward testing and approving this PR...
I see we have some common/enums.py files still in the repo for dataset_sharing and datasets_base- did we decide best to move underapi/` folder or do we want to keep it as is now?
I am open for alternative approaches / further discussion - want to align so I can help review and push this PR through

Hi @SofiaSazonova @dlpzx - what is left to be done before we can push forward testing and approving this PR...
I see we have some common/enums.py files still in the repo for dataset_sharing and datasets_base- did we decide best to move underapi/` folder or do we want to keep it as is now?
I am open for alternative approaches / further discussion - want to align so I can help review and push this PR through

@noah-paige  I moved all enums to "common" folder since they are used not only in api, but also in models and etc. If you or @dlpzx insist I can move them back to api folder, but in my opinion it's odd))

Hi @SofiaSazonova @dlpzx - what is left to be done before we can push forward testing and approving this PR...
I see we have some common/enums.py files still in the repo for dataset_sharing and datasets_base- did we decide best to move underapi/` folder or do we want to keep it as is now?
I am open for alternative approaches / further discussion - want to align so I can help review and push this PR through

@noah-paige I moved all enums to "common" folder since they are used not only in api, but also in models and etc. If you or @dlpzx insist I can move them back to api folder, but in my opinion it's odd))

In my opinion there is no need to create a new layer common in each module. db, api, services already import each other, it is not like they are independent sub-modules. I pictured layers as functional components with clearly defined purposes, common is a bit too generic and has the risk of being a "here we can store anything" layer. That's why I would add the constants to an existing layer.
Now, which one should it be? We can argue that since it is business logic they should be defined as part of services  in a file such as ml_studio_enums.py. Another option would be to add it into api because the enums inherit the class GraphQLEnumMapper.  I am 50% 50% with both options.
Another idea that I got is to rename the enums, instead of enum.py name them as modulename_enums.py to make it easier to search and manage each module separately. Similar to <modulename_models.py in db or mlstudio_service.py in services. What do you think?

I agree, that naming modulename_enums.py is much better.
As for storage of the file...I think may be then models is better? Like it's a part of field definition as well.

Also, there is no api folder in datasets_base. So, for unification I tend more to services, as you proposed

So, I moved enums to services and renamed them as module_enums

Overall  changes look good @SofiaSazonova. I am doing a last test in AWS before approving

[ ] CICD completes
[ ] Share Enum - share functionality works as expected
[ ] Dataset Enums - creation of Dataset
[ ] Organization Enums - create Organization


reordering json and amending dates to match

Coverage remained the same at 100.0% when pulling 8f88493eb0d627278e1352c30cb759632963b310 on neil into 80404b2106fa192383df2edf4e1ad7f6d500a2ce on master.


Add Rust representation of EquivalenceLibrary

Fixes #12278
Summary
As we continue our efforts to make more of the transpiler and circuit's functionality into rust. After #12459 added an infrastructure for Gates and Operations in Rust, it will be important for us to think of how to keep track of equivalent implementations of said gates that might not work in different Backends, which is why the EquivalenceLibrary exists.
The following commits add a rust representation of the EquivalenceLibrary structure.
Details and comments
Implementation:
These modifications consist of two parts:

A rust PyO3 class named: EquivalenceLibrary that implements most of the functionality of the python counterpart while keeping equivalent functionality in rust.
A python extension of the PyO3 class which is only used for the draw() method.

Modifications:

A couple of modifications were made to some of the defined structures under the qiskit._accelerate.circuit crate.

The structure Param from operations.rs now implements PartialEq and allows for comparison of instances using PyObject::is().

All conversion methods from circuit_instruction.rs have been made public to leverage usage on other crates.

Possible issues:

There is currently no way of creating a PyDiGraph natively from rust. However, rustworkx-core allows the creation of a DiGraph that has the same functionality. If an instance of PyDiGraph is needed from Python, an alternative method called graph will assemble and store a PyDiGraph instance equivalent to the one present in the EquivalenceLibrary instance. This being only a representation should not modify the internal data of the graph stored in rust and will be discarded every time an equivalency is added or modified.
This implementation uses PyO3's subclass property to allow the rust PyClass to be extended from Python. However, this might lead to unexpected behavior if one were to extend the python class, as these need to be extended using the __new__ method instead of __init__. It is highly unlikely that this class would be extended further, but it is important to note this change in behavior.

Other comments:

Feel free to leave any reviews or comments.

Nice! Did you already get to benchmark the basis translator with the oxidized equivalence library? 🙂

Not yet @Cryoris, I am having some issues with the BasisTranslator, once I look at those will get to benchmarking it.

About the failing test:
test.python.transpiler.test_basis_translator.TestBasisExamples.test_cx_bell_to_ecr
I'm considering changing that one failing test to use the equivalencies selected using the current methods since they seem to produce similarly equivalent results with the only difference being which circuit is selected for it, since it seems to be the only thing holding this redefinition back.
This is what the test does:
from qiskit.circuit import QuantumCircuit, QuantumRegister
from qiskit.converters import dag_to_circuit, circuit_to_dag
from qiskit.quantum_info import Operator
from qiskit.transpiler.passes.basis import BasisTranslator
from qiskit.circuit.equivalence_library import (StandardEquivalenceLibrary as std_eqlib)

pi: float = 3.14

"""Verify we can translate a CX bell to ECR,U."""
bell = QuantumCircuit(2)
bell.h(0)
bell.cx(0, 1)

in_dag = circuit_to_dag(bell)
out_dag = BasisTranslator(std_eqlib, ["ecr", "u"]).run(in_dag)

qr = QuantumRegister(2, "q")
expected = QuantumCircuit(2)
expected.u(pi / 2, 0, pi, qr[0])
expected.u(0, 0, -pi / 2, qr[0])
expected.u(pi, 0, 0, qr[0])
expected.u(pi / 2, -pi / 2, pi / 2, qr[1])
expected.ecr(0, 1)
expected_dag = circuit_to_dag(expected)

# Use assert_eq or just print the result
out_dag == expected_dag
Operator.from_circuit(bell) == Operator.from_circuit(dag_to_circuit(out_dag)

The problem happens when the BasisTranslator picks the equivalence for a CX gate. Where it would usually pick the following equivalence:
global phase: 7π/4
     ┌──────────┐┌───────┐┌──────┐
q_0: ┤ Rz(-π/2) ├┤ Ry(π) ├┤0     ├
     ├─────────┬┘└───────┘│  Ecr │
q_1: ┤ Rx(π/2) ├──────────┤1     ├
     └─────────┘          └──────┘

It ends up picking the following:
global phase: π/4
     ┌─────┐ ┌──────┐┌───┐
q_0: ┤ Sdg ├─┤0     ├┤ X ├
     ├─────┴┐│  Ecr │└───┘
q_1: ┤ √Xdg ├┤1     ├─────

And so the produced graph is different:
Produced:
        ┌────────────┐   ┌─────────────┐┌──────┐┌──────────┐
q_0: ───┤ U(π/2,0,π) ├───┤ U(0,0,-π/2) ├┤0     ├┤ U(π,0,π) ├
     ┌──┴────────────┴──┐└─────────────┘│  Ecr │└──────────┘
q_1: ┤ U(-π/2,-π/2,π/2) ├───────────────┤1     ├────────────

Expected:
       ┌────────────────┐  ┌──────────────┐┌─────────────┐┌──────┐
q_0: ──┤ U(1.57,0,3.14) ├──┤ U(0,0,-1.57) ├┤ U(3.14,0,0) ├┤0     ├
     ┌─┴────────────────┴─┐└──────────────┘└─────────────┘│  Ecr │
q_1: ┤ U(1.57,-1.57,1.57) ├───────────────────────────────┤1     ├

I'm curious as to what the @Qiskit/terra-core team thinks about this.

Benchmark performance:
After performing benchmarks on the redesign, it doesn't seem to make any huge differences when it comes to performance. That is, hopefully, until the BasisTranslator is moved to rust as well. Here are some results:

transpiler_benchmarks

| Change   | Before [87aa89c1] <main>   | After [e16e57bf] <move-equivalence>   |   Ratio | Benchmark (Parameter)                                                   |
|----------|----------------------------|---------------------------------------|---------|-------------------------------------------------------------------------|
|          | 3.46±0.04ms                | 3.63±0.04ms                           |    1.05 | transpiler_benchmarks.TranspilerBenchSuite.time_single_gate_compile     |
|          | 2.46±0.01ms                | 2.56±0.04ms                           |    1.04 | transpiler_benchmarks.TranspilerBenchSuite.time_cx_compile              |
|          | 517±0.8ms                  | 522±3ms                               |    1.01 | transpiler_benchmarks.TranspilerBenchSuite.time_compile_from_large_qasm |

transpiler_levels

| Change   | Before [87aa89c1] <main>   | After [e16e57bf] <move-equivalence>   |   Ratio | Benchmark (Parameter)                                                                                |
|----------|----------------------------|---------------------------------------|---------|--------------------------------------------------------------------------------------------------------|
|          | 93.3±0.08ms                | 96.0±1ms                              |    1.03 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm_backend_with_prop(0)        |
|          | 72.4±0.3ms                 | 74.5±1ms                              |    1.03 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_qv_14_x_14(0)                               |
|          | 456±3ms                    | 467±6ms                               |    1.02 | transpiler_levels.TranspilerLevelBenchmarks.time_quantum_volume_transpile_50_x_20(1)                   |
|          | 1.69±0.01s                 | 1.72±0s                               |    1.02 | transpiler_levels.TranspilerLevelBenchmarks.time_quantum_volume_transpile_50_x_20(3)                   |
|          | 140±0.5ms                  | 143±0.4ms                             |    1.02 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm(1)                          |
|          | 161±0.2ms                  | 163±2ms                               |    1.02 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm(2)                          |
|          | 166±0.4ms                  | 169±2ms                               |    1.02 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm(3)                          |
|          | 163±2ms                    | 167±2ms                               |    1.02 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm_backend_with_prop(1)        |
|          | 168±0.7ms                  | 171±1ms                               |    1.02 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm_backend_with_prop(2)        |
|          | 173±0.5ms                  | 175±3ms                               |    1.01 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm_backend_with_prop(3)        |
|          | 83.0±0.3ms                 | 84.1±2ms                              |    1.01 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_qv_14_x_14(1)                               |
|          | 226±2ms                    | 228±2ms                               |    1.01 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_qv_14_x_14(2)                               |
|          | 247±1ms                    | 250±3ms                               |    1.01 | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_qv_14_x_14(3)                               |
|          | 817±3ms                    | 819±6ms                               |    1    | transpiler_levels.TranspilerLevelBenchmarks.time_quantum_volume_transpile_50_x_20(0)                   |
|          | 1.48±0.02s                 | 1.48±0.02s                            |    1    | transpiler_levels.TranspilerLevelBenchmarks.time_quantum_volume_transpile_50_x_20(2)                   |
|          | 96.0±0.4ms                 | 95.5±0.3ms                            |    1    | transpiler_levels.TranspilerLevelBenchmarks.time_schedule_qv_14_x_14(0)                                |
|          | 85.1±0.2ms                 | 85.6±0.3ms                            |    1    | transpiler_levels.TranspilerLevelBenchmarks.time_schedule_qv_14_x_14(1)                                |
|          | 88.2±0.4ms                 | 88.5±0.9ms                            |    1    | transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm(0)                          |
|          | 2565                       | 2565                                  |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_quantum_volume_transpile_50_x_20(0)            |
|          | 1391                       | 1391                                  |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_quantum_volume_transpile_50_x_20(1)            |
|          | 1258                       | 1258                                  |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_quantum_volume_transpile_50_x_20(2)            |
|          | 1314                       | 1314                                  |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_quantum_volume_transpile_50_x_20(3)            |
|          | 2705                       | 2705                                  |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_from_large_qasm(0)                   |
|          | 2005                       | 2005                                  |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_from_large_qasm(1)                   |
|          | 7                          | 7                                     |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_from_large_qasm(2)                   |
|          | 7                          | 7                                     |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_from_large_qasm(3)                   |
|          | 2705                       | 2705                                  |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_from_large_qasm_backend_with_prop(0) |
|          | 2005                       | 2005                                  |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_from_large_qasm_backend_with_prop(1) |
|          | 7                          | 7                                     |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_from_large_qasm_backend_with_prop(2) |
|          | 7                          | 7                                     |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_from_large_qasm_backend_with_prop(3) |
|          | 323                        | 323                                   |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_qv_14_x_14(0)                        |
|          | 304                        | 304                                   |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_qv_14_x_14(1)                        |
|          | 307                        | 307                                   |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_qv_14_x_14(2)                        |
|          | 268                        | 268                                   |    1    | transpiler_levels.TranspilerLevelBenchmarks.track_depth_transpile_qv_14_x_14(3)                        |

transpiler_qualitative

| Change   | Before [87aa89c1] <main>   | After [e16e57bf] <move-equivalence>   |   Ratio | Benchmark (Parameter)                                                                                |
|----------|----------------------------|---------------------------------------|---------|---------------------------------------------------------------------------------------------------------------|
|          | 74.3±0.3ms                 | 76.3±0.4ms                            |    1.03 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(1, 'stochastic', 'sabre')    |
|          | 153±2ms                    | 158±2ms                               |    1.03 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(0, 'stochastic', 'dense')    |
|          | 59.5±0.7ms                 | 61.0±1ms                              |    1.03 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(0, 'sabre', 'sabre')             |
|          | 135±0.8ms                  | 140±2ms                               |    1.03 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(3, 'stochastic', 'sabre')        |
|          | 66.1±0.8ms                 | 67.2±0.7ms                            |    1.02 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(0, 'stochastic', 'sabre')    |
|          | 65.8±0.6ms                 | 67.3±0.5ms                            |    1.02 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(0, 'sabre', 'dense')             |
|          | 183±3ms                    | 187±3ms                               |    1.02 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(1, 'stochastic', 'sabre')        |
|          | 134±0.8ms                  | 136±2ms                               |    1.02 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(2, 'stochastic', 'sabre')        |
|          | 139±1ms                    | 142±4ms                               |    1.02 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(3, 'sabre', 'dense')             |
|          | 138±1ms                    | 140±2ms                               |    1.02 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(3, 'stochastic', 'dense')        |
|          | 69.1±0.8ms                 | 69.7±0.7ms                            |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(0, 'stochastic', 'dense')    |
|          | 47.1±0.5ms                 | 47.4±1ms                              |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(1, 'sabre', 'sabre')         |
|          | 85.4±1ms                   | 86.3±0.8ms                            |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(1, 'stochastic', 'dense')    |
|          | 94.9±0.3ms                 | 95.9±0.7ms                            |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(2, 'sabre', 'sabre')         |
|          | 189±1ms                    | 191±4ms                               |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(2, 'stochastic', 'dense')    |
|          | 234±0.8ms                  | 235±3ms                               |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(3, 'stochastic', 'dense')    |
|          | 174±0.6ms                  | 175±2ms                               |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(3, 'stochastic', 'sabre')    |
|          | 63.6±0.2ms                 | 64.3±0.7ms                            |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(0, 'sabre', 'dense')         |
|          | 192±2ms                    | 194±2ms                               |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(1, 'stochastic', 'sabre')    |
|          | 252±0.8ms                  | 254±2ms                               |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(2, 'sabre', 'dense')         |
|          | 313±3ms                    | 315±3ms                               |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(3, 'sabre', 'dense')         |
|          | 136±1ms                    | 138±3ms                               |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(2, 'sabre', 'dense')             |
|          | 135±0.7ms                  | 136±2ms                               |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(2, 'sabre', 'sabre')             |
|          | 135±0.4ms                  | 137±2ms                               |    1.01 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(3, 'sabre', 'sabre')             |
|          | 38.0±0.2ms                 | 38.0±0.3ms                            |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(0, 'sabre', 'dense')         |
|          | 34.2±0.5ms                 | 34.1±0.1ms                            |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(0, 'sabre', 'sabre')         |
|          | 51.8±0.8ms                 | 51.6±0.3ms                            |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(1, 'sabre', 'dense')         |
|          | 146±3ms                    | 146±3ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(2, 'stochastic', 'sabre')    |
|          | 131±3ms                    | 131±0.9ms                             |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(3, 'sabre', 'dense')         |
|          | 118±0.7ms                  | 118±1ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(3, 'sabre', 'sabre')         |
|          | 58.1±0.6ms                 | 58.1±0.3ms                            |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(0, 'sabre', 'sabre')         |
|          | 156±0.6ms                  | 156±2ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(0, 'stochastic', 'sabre')    |
|          | 95.6±1ms                   | 95.7±0.9ms                            |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(1, 'sabre', 'dense')         |
|          | 93.9±1ms                   | 93.9±0.9ms                            |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(1, 'sabre', 'sabre')         |
|          | 240±0.7ms                  | 238±2ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(2, 'sabre', 'sabre')         |
|          | 375±2ms                    | 375±4ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(2, 'stochastic', 'dense')    |
|          | 418±2ms                    | 419±1ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(2, 'stochastic', 'sabre')    |
|          | 302±2ms                    | 303±2ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(3, 'sabre', 'sabre')         |
|          | 136±1ms                    | 135±1ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(0, 'stochastic', 'dense')        |
|          | 141±3ms                    | 140±1ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(0, 'stochastic', 'sabre')        |
|          | 102±0.9ms                  | 101±1ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(1, 'sabre', 'dense')             |
|          | 186±1ms                    | 186±1ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(1, 'stochastic', 'dense')        |
|          | 137±2ms                    | 138±2ms                               |    1    | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(2, 'stochastic', 'dense')        |
|          | 257                        | 257                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(0, 'sabre', 'dense')      |
|          | 241                        | 241                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(0, 'sabre', 'sabre')      |
|          | 227                        | 227                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(0, 'stochastic', 'dense') |
|          | 237                        | 237                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(0, 'stochastic', 'sabre') |
|          | 218                        | 218                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(1, 'sabre', 'dense')      |
|          | 212                        | 212                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(1, 'sabre', 'sabre')      |
|          | 218                        | 218                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(1, 'stochastic', 'dense') |
|          | 221                        | 221                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(1, 'stochastic', 'sabre') |
|          | 267                        | 267                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(2, 'sabre', 'dense')      |
|          | 244                        | 244                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(2, 'sabre', 'sabre')      |
|          | 257                        | 257                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(2, 'stochastic', 'dense') |
|          | 278                        | 278                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(2, 'stochastic', 'sabre') |
|          | 267                        | 267                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(3, 'sabre', 'dense')      |
|          | 244                        | 244                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(3, 'sabre', 'sabre')      |
|          | 257                        | 257                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(3, 'stochastic', 'dense') |
|          | 278                        | 278                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4gt10_v1_81(3, 'stochastic', 'sabre') |
|          | 55                         | 55                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(0, 'sabre', 'dense')      |
|          | 58                         | 58                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(0, 'sabre', 'sabre')      |
|          | 54                         | 54                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(0, 'stochastic', 'dense') |
|          | 53                         | 53                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(0, 'stochastic', 'sabre') |
|          | 51                         | 51                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(1, 'sabre', 'dense')      |
|          | 48                         | 48                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(1, 'sabre', 'sabre')      |
|          | 43                         | 43                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(1, 'stochastic', 'dense') |
|          | 53                         | 53                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(1, 'stochastic', 'sabre') |
|          | 66                         | 66                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(2, 'sabre', 'dense')      |
|          | 53                         | 53                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(2, 'sabre', 'sabre')      |
|          | 64                         | 64                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(2, 'stochastic', 'dense') |
|          | 68                         | 68                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(2, 'stochastic', 'sabre') |
|          | 66                         | 66                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(3, 'sabre', 'dense')      |
|          | 53                         | 53                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(3, 'sabre', 'sabre')      |
|          | 64                         | 64                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(3, 'stochastic', 'dense') |
|          | 68                         | 68                                    |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_4mod5_v0_19(3, 'stochastic', 'sabre') |
|          | 610                        | 610                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(0, 'sabre', 'dense')      |
|          | 558                        | 558                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(0, 'sabre', 'sabre')      |
|          | 522                        | 522                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(0, 'stochastic', 'dense') |
|          | 545                        | 545                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(0, 'stochastic', 'sabre') |
|          | 507                        | 507                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(1, 'sabre', 'dense')      |
|          | 494                        | 494                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(1, 'sabre', 'sabre')      |
|          | 469                        | 469                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(1, 'stochastic', 'dense') |
|          | 498                        | 498                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(1, 'stochastic', 'sabre') |
|          | 592                        | 592                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(2, 'sabre', 'dense')      |
|          | 585                        | 585                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(2, 'sabre', 'sabre')      |
|          | 601                        | 601                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(2, 'stochastic', 'dense') |
|          | 638                        | 638                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(2, 'stochastic', 'sabre') |
|          | 592                        | 592                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(3, 'sabre', 'dense')      |
|          | 585                        | 585                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(3, 'sabre', 'sabre')      |
|          | 601                        | 601                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(3, 'stochastic', 'dense') |
|          | 638                        | 638                                   |    1    | transpiler_qualitative.TranspilerQualitativeBench.track_depth_transpile_mod8_10_178(3, 'stochastic', 'sabre') |
|          | 87.2±0.7ms                 | 86.6±0.4ms                            |    0.99 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(2, 'sabre', 'dense')         |
|          | 429±4ms                    | 426±4ms                               |    0.99 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(3, 'stochastic', 'dense')    |
|          | 528±4ms                    | 522±3ms                               |    0.99 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(3, 'stochastic', 'sabre')    |
|          | 96.2±0.8ms                 | 94.8±0.7ms                            |    0.99 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(1, 'sabre', 'sabre')             |
|          | 201±4ms                    | 196±1ms                               |    0.97 | transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(1, 'stochastic', 'dense')    |

mapping_passes

| Change   | Before [87aa89c1] <main>   | After [e16e57bf] <move-equivalence>   |   Ratio | Benchmark (Parameter)                                                                                |
|----------|----------------------------|---------------------------------------|---------|---------------------------------------------------------------------------------------------------------|
|          | 8.98±0.1ms                 | 9.27±0.3ms                            |    1.03 | mapping_passes.PassBenchmarks.time_layout_2q_distance(14, 1024)                                         |
|          | 45.8±0.4ms                 | 47.1±0.8ms                            |    1.03 | mapping_passes.PassBenchmarks.time_sabre_swap(5, 1024)                                                  |
|          | 8.15±0.06ms                | 8.41±0.3ms                            |    1.03 | mapping_passes.RoutedPassBenchmarks.time_check_map(5, 1024)                                             |
|          | 8.28±0.08ms                | 8.56±0.3ms                            |    1.03 | mapping_passes.RoutedPassBenchmarks.time_gate_direction(5, 1024)                                        |
|          | 54.3±0.2ms                 | 55.3±0.4ms                            |    1.02 | mapping_passes.PassBenchmarks.time_apply_layout(14, 1024)                                               |
|          | 81.3±2ms                   | 82.9±1ms                              |    1.02 | mapping_passes.PassBenchmarks.time_apply_layout(20, 1024)                                               |
|          | 19.1±0.07ms                | 19.5±0.2ms                            |    1.02 | mapping_passes.PassBenchmarks.time_apply_layout(5, 1024)                                                |
|          | 2.19±0.01s                 | 2.23±0.01s                            |    1.02 | mapping_passes.PassBenchmarks.time_basic_swap(14, 1024)                                                 |
|          | 3.56±0.01s                 | 3.62±0s                               |    1.02 | mapping_passes.PassBenchmarks.time_basic_swap(20, 1024)                                                 |
|          | 6.77±0.1ms                 | 6.88±0.06ms                           |    1.02 | mapping_passes.PassBenchmarks.time_check_map(14, 1024)                                                  |
|          | 274±2ms                    | 278±1ms                               |    1.02 | mapping_passes.PassBenchmarks.time_sabre_layout(14, 1024)                                               |
|          | 454±4ms                    | 461±3ms                               |    1.02 | mapping_passes.PassBenchmarks.time_sabre_layout(20, 1024)                                               |
|          | 145±0.4ms                  | 149±0.7ms                             |    1.02 | mapping_passes.PassBenchmarks.time_sabre_swap(14, 1024)                                                 |
|          | 229±0.8ms                  | 234±1ms                               |    1.02 | mapping_passes.PassBenchmarks.time_sabre_swap(20, 1024)                                                 |
|          | 43.5±0.9ms                 | 44.2±0.3ms                            |    1.02 | mapping_passes.RoutedPassBenchmarks.time_check_gate_direction(14, 1024)                                 |
|          | 82.6±0.9ms                 | 83.8±2ms                              |    1.02 | mapping_passes.RoutedPassBenchmarks.time_check_gate_direction(20, 1024)                                 |
|          | 9.19±0.07ms                | 9.41±0.2ms                            |    1.02 | mapping_passes.RoutedPassBenchmarks.time_check_gate_direction(5, 1024)                                  |
|          | 34.9±0.4ms                 | 35.5±0.5ms                            |    1.02 | mapping_passes.RoutedPassBenchmarks.time_gate_direction(14, 1024)                                       |
|          | 59.4±0.4ms                 | 60.4±1ms                              |    1.02 | mapping_passes.RoutedPassBenchmarks.time_gate_direction(20, 1024)                                       |
|          | 605±5ms                    | 610±4ms                               |    1.01 | mapping_passes.PassBenchmarks.time_basic_swap(5, 1024)                                                  |
|          | 7.20±0.08μs                | 7.24±0.03μs                           |    1.01 | mapping_passes.PassBenchmarks.time_enlarge_with_ancilla(14, 1024)                                       |
|          | 13.4±0.03μs                | 13.5±0.06μs                           |    1.01 | mapping_passes.PassBenchmarks.time_full_ancilla_allocation(5, 1024)                                     |
|          | 12.6±0.08ms                | 12.7±0.2ms                            |    1.01 | mapping_passes.PassBenchmarks.time_layout_2q_distance(20, 1024)                                         |
|          | 72.7±0.5ms                 | 73.4±0.8ms                            |    1.01 | mapping_passes.PassBenchmarks.time_sabre_layout(5, 1024)                                                |
|          | 14.2±0.1μs                 | 14.3±0.1μs                            |    1.01 | mapping_passes.PassBenchmarks.time_set_layout(5, 1024)                                                  |
|          | 41.8±0.1μs                 | 42.1±0.3μs                            |    1.01 | mapping_passes.PassBenchmarks.time_trivial_layout(5, 1024)                                              |
|          | 2.50±0.02ms                | 2.51±0.05ms                           |    1    | mapping_passes.PassBenchmarks.time_check_map(5, 1024)                                                   |
|          | 5.61±0.03ms                | 5.64±0.03ms                           |    1    | mapping_passes.PassBenchmarks.time_csp_layout(5, 1024)                                                  |
|          | 324±10μs                   | 323±7μs                               |    1    | mapping_passes.PassBenchmarks.time_dense_layout(5, 1024)                                                |
|          | 7.27±0.07μs                | 7.28±0.1μs                            |    1    | mapping_passes.PassBenchmarks.time_enlarge_with_ancilla(5, 1024)                                        |
|          | 13.4±0.08μs                | 13.4±0.07μs                           |    1    | mapping_passes.PassBenchmarks.time_full_ancilla_allocation(20, 1024)                                    |
|          | 3.29±0.06ms                | 3.27±0.05ms                           |    1    | mapping_passes.PassBenchmarks.time_layout_2q_distance(5, 1024)                                          |
|          | 14.2±0.1μs                 | 14.2±0.1μs                            |    1    | mapping_passes.PassBenchmarks.time_set_layout(14, 1024)                                                 |
|          | 1.32±0s                    | 1.31±0s                               |    1    | mapping_passes.PassBenchmarks.time_stochastic_swap(14, 1024)                                            |
|          | 1.91±0.01s                 | 1.91±0.01s                            |    1    | mapping_passes.PassBenchmarks.time_stochastic_swap(20, 1024)                                            |
|          | 41.3±0.3μs                 | 41.5±0.2μs                            |    1    | mapping_passes.PassBenchmarks.time_trivial_layout(20, 1024)                                             |
|          | 17                         | 17                                    |    1    | statepreparation.StatePreparationTranspileBench.track_cnot_counts_after_mapping_to_ibmq_16_melbourne(4) |
|          | 47                         | 47                                    |    1    | statepreparation.StatePreparationTranspileBench.track_cnot_counts_after_mapping_to_ibmq_16_melbourne(5) |
|          | 111                        | 111                                   |    1    | statepreparation.StatePreparationTranspileBench.track_cnot_counts_after_mapping_to_ibmq_16_melbourne(6) |
|          | 231                        | 231                                   |    1    | statepreparation.StatePreparationTranspileBench.track_cnot_counts_after_mapping_to_ibmq_16_melbourne(7) |
|          | 460                        | 460                                   |    1    | statepreparation.StatePreparationTranspileBench.track_cnot_counts_after_mapping_to_ibmq_16_melbourne(8) |
|          | 19.5±0.2ms                 | 19.3±0.2ms                            |    0.99 | mapping_passes.PassBenchmarks.time_csp_layout(14, 1024)                                                 |
|          | 7.08±0.04μs                | 7.02±0.03μs                           |    0.99 | mapping_passes.PassBenchmarks.time_enlarge_with_ancilla(20, 1024)                                       |
|          | 13.5±0.06μs                | 13.3±0.03μs                           |    0.99 | mapping_passes.PassBenchmarks.time_full_ancilla_allocation(14, 1024)                                    |
|          | 14.3±0.07μs                | 14.2±0.07μs                           |    0.99 | mapping_passes.PassBenchmarks.time_set_layout(20, 1024)                                                 |
|          | 386±4ms                    | 381±2ms                               |    0.99 | mapping_passes.PassBenchmarks.time_stochastic_swap(5, 1024)                                             |
|          | 35.1±0.6ms                 | 34.7±1ms                              |    0.99 | mapping_passes.RoutedPassBenchmarks.time_check_map(14, 1024)                                            |
|          | 61.0±0.5ms                 | 60.6±0.9ms                            |    0.99 | mapping_passes.RoutedPassBenchmarks.time_check_map(20, 1024)                                            |
|          | 9.74±0.3ms                 | 9.55±0.1ms                            |    0.98 | mapping_passes.PassBenchmarks.time_check_map(20, 1024)                                                  |
|          | 32.2±0.6ms                 | 31.6±0.5ms                            |    0.98 | mapping_passes.PassBenchmarks.time_csp_layout(20, 1024)                                                 |
|          | 321±5μs                    | 315±7μs                               |    0.98 | mapping_passes.PassBenchmarks.time_dense_layout(14, 1024)                                               |
|          | 42.6±0.4μs                 | 41.9±0.3μs                            |    0.98 | mapping_passes.PassBenchmarks.time_trivial_layout(14, 1024)                                             |
|          | 340±10μs                   | 324±8μs                               |    0.95 | mapping_passes.PassBenchmarks.time_dense_layout(20, 1024)                                               |

I'm still continuously testing this structure, so please let me know of any concerns you may have while I continue, thank you for your time.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

409 of 543 (75.32%)  changed or added relevant lines in 8 files are covered.
13 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.1%) to 89.653%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/operations.rs
12
25
48.0%

crates/circuit/src/equivalence.rs
387
503
76.94%

Files with Coverage Reduction
New Missed Lines
%

qiskit/circuit/equivalence.py
2
27.27%

crates/qasm2/src/lex.rs
5
92.88%

crates/qasm2/src/parse.rs
6
97.61%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
64113

Relevant Lines:
71512

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

409 of 543 (75.32%)  changed or added relevant lines in 8 files are covered.
10 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.08%) to 89.638%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/operations.rs
12
25
48.0%

crates/circuit/src/equivalence.rs
387
503
76.94%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
2
93.13%

qiskit/circuit/equivalence.py
2
27.27%

crates/qasm2/src/parse.rs
6
96.69%

Totals

Change from base Build<PHONE_NUMBER>:
-0.08%

Covered Lines:
64102

Relevant Lines:
71512

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

409 of 543 (75.32%)  changed or added relevant lines in 8 files are covered.
14 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.09%) to 89.674%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/operations.rs
12
25
48.0%

crates/circuit/src/equivalence.rs
387
503
76.94%

Files with Coverage Reduction
New Missed Lines
%

qiskit/circuit/equivalence.py
2
27.27%

crates/qasm2/src/lex.rs
6
93.13%

crates/qasm2/src/parse.rs
6
97.61%

Totals

Change from base Build<PHONE_NUMBER>:
-0.09%

Covered Lines:
64135

Relevant Lines:
71520

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

409 of 543 (75.32%)  changed or added relevant lines in 8 files are covered.
6 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.08%) to 89.67%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/operations.rs
12
25
48.0%

crates/circuit/src/equivalence.rs
387
503
76.94%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

qiskit/circuit/equivalence.py
2
27.27%

crates/qasm2/src/lex.rs
3
92.62%

Totals

Change from base Build<PHONE_NUMBER>:
-0.08%

Covered Lines:
64132

Relevant Lines:
71520

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

401 of 539 (74.4%)  changed or added relevant lines in 8 files are covered.
311 unchanged lines in 12 files lost coverage.
Overall coverage decreased (-0.1%) to 89.631%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/operations.rs
10
24
41.67%

crates/circuit/src/equivalence.rs
381
500
76.2%

Files with Coverage Reduction
New Missed Lines
%

crates/accelerate/src/isometry.rs
1
99.65%

crates/accelerate/src/sampled_exp_val.rs
1
88.71%

qiskit/circuit/equivalence.py
2
27.27%

crates/accelerate/src/convert_2q_block_matrix.rs
3
93.02%

crates/circuit/src/imports.rs
3
77.78%

crates/qasm2/src/lex.rs
7
91.6%

crates/accelerate/src/pauli_exp_val.rs
8
89.68%

crates/qasm2/src/parse.rs
12
96.69%

crates/accelerate/src/sparse_pauli_op.rs
15
93.27%

crates/accelerate/src/euler_one_qubit_decomposer.rs
20
89.68%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
64128

Relevant Lines:
71547

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

403 of 540 (74.63%)  changed or added relevant lines in 8 files are covered.
29 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.1%) to 89.635%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/operations.rs
12
25
48.0%

crates/circuit/src/equivalence.rs
381
500
76.2%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

qiskit/circuit/equivalence.py
2
27.27%

crates/circuit/src/imports.rs
3
77.78%

crates/qasm2/src/lex.rs
5
91.86%

crates/qasm2/src/parse.rs
18
96.69%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
64131

Relevant Lines:
71547

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

406 of 509 (79.76%)  changed or added relevant lines in 8 files are covered.
185 unchanged lines in 11 files lost coverage.
Overall coverage decreased (-0.07%) to 89.681%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/operations.rs
12
25
48.0%

crates/circuit/src/equivalence.rs
384
469
81.88%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

qiskit/circuit/library/standard_gates/rz.py
2
95.83%

qiskit/circuit/library/standard_gates/ry.py
2
95.95%

qiskit/circuit/equivalence.py
2
27.27%

qiskit/circuit/library/standard_gates/rx.py
2
96.05%

crates/circuit/src/imports.rs
3
77.78%

crates/circuit/src/circuit_instruction.rs
4
95.93%

crates/qasm2/src/lex.rs
4
92.11%

crates/qasm2/src/parse.rs
18
96.69%

qiskit/circuit/quantumcircuit.py
24
95.51%

Totals

Change from base Build<PHONE_NUMBER>:
-0.07%

Covered Lines:
64241

Relevant Lines:
71633

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

411 of 513 (80.12%)  changed or added relevant lines in 8 files are covered.
35 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.05%) to 89.791%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/operations.rs
12
25
48.0%

crates/circuit/src/equivalence.rs
389
473
82.24%

Files with Coverage Reduction
New Missed Lines
%

qiskit/transpiler/passes/routing/commuting_2q_gate_routing/pauli_2q_evolution_commutation.py
1
97.92%

qiskit/transpiler/passes/synthesis/unitary_synthesis.py
2
88.2%

qiskit/circuit/equivalence.py
2
27.27%

crates/qasm2/src/lex.rs
3
92.88%

qiskit/dagcircuit/dagcircuit.py
27
92.1%

Totals

Change from base Build<PHONE_NUMBER>:
-0.05%

Covered Lines:
64763

Relevant Lines:
72126

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

403 of 523 (77.06%)  changed or added relevant lines in 7 files are covered.
35 unchanged lines in 6 files lost coverage.
Overall coverage decreased (-0.1%) to 89.706%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/operations.rs
0
25
0.0%

crates/circuit/src/equivalence.rs
396
486
81.48%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

qiskit/transpiler/passes/synthesis/unitary_synthesis.py
2
88.35%

qiskit/circuit/equivalence.py
2
27.27%

crates/qasm2/src/lex.rs
3
92.62%

crates/circuit/src/imports.rs
3
77.78%

crates/qasm2/src/parse.rs
24
96.23%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
65431

Relevant Lines:
72939

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

408 of 515 (79.22%)  changed or added relevant lines in 6 files are covered.
13 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.08%) to 89.77%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/equivalence.rs
401
503
79.72%

Files with Coverage Reduction
New Missed Lines
%

crates/accelerate/src/synthesis/linear/mod.rs
2
93.55%

qiskit/circuit/equivalence.py
2
27.27%

crates/circuit/src/imports.rs
3
77.78%

crates/qasm2/src/lex.rs
6
92.37%

Totals

Change from base Build<PHONE_NUMBER>:
-0.08%

Covered Lines:
65532

Relevant Lines:
73000

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

408 of 515 (79.22%)  changed or added relevant lines in 6 files are covered.
21 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.1%) to 89.778%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/circuit/src/imports.rs
0
1
0.0%

qiskit/circuit/equivalence.py
3
7
42.86%

crates/circuit/src/equivalence.rs
401
503
79.72%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

qiskit/circuit/equivalence.py
2
27.27%

crates/qasm2/src/lex.rs
4
92.11%

crates/qasm2/src/parse.rs
6
96.69%

qiskit/synthesis/clifford/clifford_decompose_ag.py
8
88.46%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
66062

Relevant Lines:
73584

💛  - Coveralls


Handling \r & \n on CLI

Lifted from @Godnoken https://github.com/XapaJIaMnu/translateLocally/pull/81#issuecomment-1264353934

I'm sorry if this is not on topic as you are talking about HTML primarily.
I noticed that I can't successfully translate texts that contain \n through the command line I "fixed" it by substituting \n with another symbol like * during translation and then vice versa after the translation is done. It works sometimes but often not, due to my text input having different sets of \n, \r and so on.
Is there or would there be a way to ignore all sorts of carriage returns?
Edit
Hmm, apologies. It seems like it does indeed translate with no problems and automatically removes all carriage returns on the command line. The issue I had must have had to do with Tauri.
I'll revise my question - Would it be possible to implement an option to only ignore \n & \r but not remove them?

Can we add a command line option that makes translateLocally CLI not treat a new line as a paragraph boundary?
I'm aware the sentence splitter has a mode where it just ignores newlines, and will treat them as tokens in the sentence. I'm not sure how these survive the translation. I'm assuming they'd need to be part of the vocab? None of our models are trained on sentences that contain newlines.

Pretty sure the sentence splitter, when configured to unwrap lines, just replaces newline with space.  There is no formatting preservation there.  I guess we could do something alignment based, but the main use case for this is wrapped text with what are effectively soft returns.  And soft returns just go back at column width, not a semantic position.


Random circuit generator

Can initially actually just be a polynomial generator. We don't need to specifically perform any kind of IOP but only the proof generation part for now while we work on the initial Pianist impl


Validation error redirects to /

Hi, I've got a simple form that is redirecting to / when there is validation errors rather than staying on the page and showing the errors. I am using ziggy but ziggy worked fine previously.
<form onSubmit={SubmitForm}>

post(route('contact.submit'));

import '../css/app.css';
import './bootstrap';

import { createInertiaApp } from '@inertiajs/react';
import { resolvePageComponent } from 'laravel-vite-plugin/inertia-helpers';
import { createRoot, hydrateRoot } from 'react-dom/client';

import TimeAgo from 'javascript-time-ago';
import en from 'javascript-time-ago/locale/en';

TimeAgo.addDefaultLocale(en);
TimeAgo.addLocale(en);

const appName = import.meta.env.VITE_APP_NAME || 'Pretty URL';

createInertiaApp({
    title: (title) => `${title} - ${appName}`,
    resolve: (name) => {
        const pages = import.meta.glob('./Pages/**/*.tsx');
        return resolvePageComponent(`./Pages/${name}.tsx`, pages);
    },
    setup({ el, App, props }) {
        if (import.meta.env.SSR) {
            hydrateRoot(el, <App {...props} />);
            return;
        }

        createRoot(el).render(<App {...props} />);
    },
    progress: {
        color: '#3b82f6',
    },
});

This previously worked fine but I'm unsure what's going on now? Happens on any page, any form. I've clearly messed something up somewhere but does anyone have any ideas what it could be?

I just noticed I posted this on the wrong repo, but I fixed it.
Weirdly, <meta name="referrer" content="origin"> is the cause but I'm not sure why..


Added Suiware Faucet Chrome Extension

Hi @kkomelin
It is awesome to see a new extension here. I try the extension and find out there is bug in the extension, and the issue page of the repo is closed.  Would you open the issue tag and also solve these bugs.

the extension does not memory previous devnet and testnet setting.
the testnet is not really work with following error from my end.

Thank you very much @yanganto for your feedback!
Let me address the issues you mentioned one by one...

I've opened the issue queue for the extension repository. Good catch! https://github.com/suiware/suiware-faucet-extension/issues

I've created an issue for your feature request https://github.com/suiware/suiware-faucet-extension/issues/1

The bug you described (https://github.com/suiware/suiware-faucet-extension/issues/2) unfortunately cannot be fixed currently because of the limitations of the official faucet API which the extension uses. However, there is some hope that the official faucet API limitations will be revised in the future. I reported the issue to the team.


SeekArc with two different color

Hello @neild001 ,
can u plz help me out

I want to fill two colors in a curve. As I attached screen shot of here you can see two colors (one is gray and attached red colored line). I can draw gray curve line but not able to draw red line which is attached with gray line.
So requested you to plz tell me about fill curve with two different color.

Couldn't you just set a seekArc on top of another seekArc and adjust the padding on one to make it slightly larger than the other?


How to fetch metadata such as number of entries?

Hi there,
I have been using this to test reactjs apps. Is there a way to fetch metadata such as number of entries?

haven't tried this API out yet but I am currently working on a similar task, have you tried Object.keys(object).length?

it's okay @alex2118 I have decided to build my own API. Thanks 👍


Notification Checker

I want to check if a specific notification has been received and if it has then it should send a message to a particular person.

@Fractal393 there's no built-in way to do this, for privacy and technical reasons.  If you're having trouble with notification delivery please contact Firebase support.  If you need general help writing your app please try StackOverflow.  Thanks!