text:
Validation Error using Intermediate Message Catch Event

When create an Intermediate Message Catch Event, its  is being saved/created with invalid properties that is causing and validation error on saving the xml diagram.
If the Message Event Identifier is empty:

The attribute variableName is not defined in the XSD nor moddle extension, the defined attribute in the PRD and in the latest version of the XSD and the moddle extension is "dataName" so using variableName is causing an validation error here:

PM4-IntermediateMessageCatchEvent-PRD-290519-1556.pdf

@caleeli @velkymx
Data name was renamed to variable name.
Issue: https://github.com/ProcessMaker/spark-modeler/issues/356
PR: https://github.com/ProcessMaker/spark-modeler/pull/360
I believe this change also needs to happen in processmaker-bpmn-moddle.

Could be good to have an initial default value for the "Message Event Identifier" that could be "message"

repo: ProcessMaker/spark-modeler


text:
Incorrect game view for large head rotations (close to 90deg)

When pitch is close to 90 degrees, applying a yaw simultaneously translates to an incorrect view.
This is caused by a different order in the rotation axes between the decomposition of the HMD pose matrix and the application of the angles in the game engine.
We need to replace quatToEuler() with a function that asumes an intrinsic pitch-then-yaw convention

A nice illustration of the issue
https://towardsdatascience.com/better-rotation-representations-for-accurate-pose-estimation-e890a7e1317f?gi=4b1e26554fbc

This was solved with Matrix multiplication based headtracking, as implemented in the new pose_corrected_headtracking mode.

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
adds the bounding box generation script

Signed-off-by: Wenqi Li wenqil@nvidia.com
Description
the bbox_gen was used as a preprcoessing step of https://github.com/Project-MONAI/tutorials/blob/master/modules/interpretability/class_lung_lesion.ipynb
Status
Ready
Checks

[ ] Notebook runs automatically ./runner [-p <regex_pattern>]

I think I removed the call to bbox_gen.py in the tutorial, and so I deleted the file in the repository. I thought the notebook was cleaner to simply download from google drive every time. What do you think?

I see, the script is mainly to show how the image patches are generated, there are some non-standard tricks to remove tiny lesions. just wanted to make them transparent/reproducible to the users...

source: gharchive/pull-request

authors: rijobro wyli

repo: Project-MONAI/tutorials


text:
486 Add inference example for bundle

part of #486
Description
This PR added inference example for monai.bundle.
Status
Work in progress
Checks

[ ] Notebook runs automatically ./runner [-p <regex_pattern>]

Command to run from shell:
python -m monai.bundle.scripts run --meta_file="configs/metadata.json" --config_file="configs/inference.json" --target="evaluator"

PR is ready for review, it depends on: https://github.com/Project-MONAI/MONAI/pull/3994.
Thanks.


text:
Update Multiple Instance Learning Pipeline

Fixes #637
Description
This PR updates Multiple Instance Learning Pipeline with the new components in MONAI.
Status
Ready
Checks

[ ] Notebook runs automatically ./runner [-p <regex_pattern>]

@Nic-Ma Here is the accuracy metric of the updated pipeline with respect to the original one that Andriy has run the experiment and produced the figures. The dark blue is the original one and the orange is the updated one (ignore the other colors). Both dark blue and orange ones are performing very similarly considering the different randomness that they have.

@Nic-Ma I believe this pipeline is already tested by @myron and equivalent performance is reported. Can you please help to merge it?


text:
Rewrite & update the "About" content

As mentioned in #115, regarding the new portal landing page, @brian-rose mentioned:

I think the paragraph under the "Project Pythia" heading is too verbose, seeing as it's the first thing people see when they hit the page. I think we can come up something snappier that describes the project in a few short catchphrases, and leave the details to the "About" page.

and further:

The "About" page needs updating to better reflect where we are and where we are aiming with our content.

With the merge of #115, I am moving these suggestions to this issue.

As discussed at today's EWG, I will take a stab at these changes in a new PR.

I am re-committing myself (again) to getting this done, and making sure that the link to Pangeo is spelled out on the landing page.

Can we close this with the merger of #215, and further landing-page improvements in #227?

authors: brian-rose kmpaul


text:
Bug - Bottom Tooltip "Ausgangstür" wird permanent angezeigt

User Story
Nach dem ersten Raum wird der Bottom Tooltip für die Ausgangstür permanent angezeigt, solange kein anderer Bottom Toolltip über Mouse-Hover oder Avatar-Annäherung aufgerufen wird.

Akzeptanzkriterien

[ ] Akzeptanzkriterium 1
[ ] Akzeptanzkriterium 2

Definition of Ready

[ ] User Story ist klein genug für Sprint
[ ] User Story ist für jeden beteiligten Entwickler klar verständlich
[ ] User Story Aufwand ist geschätzt
[ ] User Story hat Akzeptanzkriterien
[ ] User Story hat einen Mehrwert für das Produkt oder die Entwicklung
[ ] User Story Ursprung ist bekannt (Stakeholder)
[ ] User Story ist Release zugewiesen

Definition of Done

[ ] Alle Akzeptanzkriterien sind erfüllt
[ ] Die Implementierung ist gepusht
[ ] Die Codekonventionen sind eingehalten
[ ] Eine Code Review wurde durchgeführt (oder in Paired Programming gearbeitet)
[ ] Unittestabdeckung muss größer 92% sein
[ ] Alle Tests müssen bestanden sein
[ ] Technische Dokumentation innerhalb der Realisierung wurde, falls nötig, erstellt (Quellcode)
[ ] Benutzerdokumentation wurde, falls nötig, angelegt (Wiki)
[ ] Dokumentation des Vorgehens wurde, falls nötig, angelegt (Zenhub Kommentar)
[ ] UML Aktivitätsdiagramm wurde erstellt bzw. aktualisiert falls nötig
[ ] Changelog des jeweiligen Release wurde aktualisiert, falls erforderlich (Wiki)
[ ] Es gibt keine bekannten Bugs
[ ] Die Realisierung der User Story wurde erfolgreich durch den Product Owner abgenommen

Hey team! Please add your planning poker estimate with Zenhub @DerKatsche @Grunick @Lizardguard

authors: AdLer-Lukas splican


text:
[UI] Drag&Drop von Elementen ist fehlerhaft

Beschreibung des Problems:
Wenn man ein Element aus der Liste unplatzierter Elemente mit der Maustaste greift und in einen Slot ziehen möchte, dann werden Elemente teilweise abgeschnitten oder die Fläche um das Element herum mit gezogen.
Erwartetes Verhalten:
Nur das Element wird bei einer Drag&Drop-Anwendung in den Slot gezogen.
Ansprechpartner:
Antonia
Lösung (erst bei Fix angeben):

Dropzone darf kein Overflow-scroll haben (Div um die Muddropzone)
z-index für die Dropzone
MudIconButton tauschen durch button mit MudIcon

repo: ProjektAdLer/Autorentool


text:
[BUG] When Exporting a Request/Response Body, the file name doesn't contain the file extension

Description
As title.
Steps to Reproduce

Open Proxyman for Windows -> Open this URL: https://user-images.githubusercontent.com/5878421/258680109-dd5d2543-024b-4a7a-9eeb-4b8b0046c5a3.jpg
Enable SSL Proxying on this domain -> Re-send the URL again
Right-click on new request -> Export -> Response Body
Save to the desktop with the default name

Current Behavior

The file doesn't contain the File Extension -> Can't double click to open it

Expected Behavior

Should detect the file format, and add the file extension properly.

How to detect the file extension

Try to parse the URL (Use NodeJS Path: https://nodejs.org/api/path.html#pathextnamepath) -> If it contains the files extension -> Use it
If there is no file extension, use this lib file-type to detect the bytes -> Get extension
Otherwise, if there are no extensions, just don't add the extension to the file filename.

Test cases

Test with PNG, JPG
PDF, MP4
Text-base (txt)

Environment

App version:
Windows/Linux version:

Unable to reproduce the bug, but I will add unit tests and update the code of the export function

It seems I can't reproduce the bug anymore. I will close this ticket for further investigation.

repo: ProxymanApp/proxyman-windows-linux


text:
feat: utterances 추가

Resolve #23
Task
저희 jupyter book에 utterances을 활용하여 댓글 기능을 추가하였습니다. [#23]
Test
utterances 기능 특성상 로컬에선 테스트가 불가합니다..!!

@heehehe 앗 감사합니다😃😃!!


text:
IPv6

لطفا این قابلیت رو اضافه کنید که همگام نصب بشه تانل آیپی۶ رو انجام بده و داخل سرویسهای گوست هم ست بشه .

الان هم میتونید اسنفاده کنید فقط ipv6 را داخل [ ] بزارید مثل : [2a01:4f8:1c1b:2795::1]

authors: MILADALEF Ptechgithub

repo: Ptechgithub/Gost


text:
Add server console shortcut on every server list on the admin panel

In the list of associated servers on the detail page of users we have shortcuts to the console of the servers. We should add that shortcut to all server lists and also replace the link to the console on the server admin page with the same icon (tachometer) for consitency.

We should also consider adding a second icon (or using just one) that opens the console in the popup window for very quick and dirty console management of the server rather than loading the whole page and leaving the ACP.

authors: DaneEveritt schrej

repo: Pterodactyl/Panel

license: mit

license_source: bigquery


text:
Replace Snabbdom

Snabbdom is the JS Virtual DOM implementation that powers Tyrian's rendering at the moment.
I'd like to investigate replacing it with a pure Scala.js Incremental DOM (or something).
The point of this is to make the SPA and SSR rendering happen via the same process.
Step one is to do the naive thing and just re-render on-change, and replace the innerHtml of the top level element completely. That will work (probably), but will be slow (probably, but is cheap memory-wise), everything after that is an optimisation.

We'll need a way to run tests in the browser so we can talk to a real DOM - there is a Scala.js selenium thing for that.
We could also do with figuring out a way to benchmark this compared a) to Snabbdom and b) to other solutions, like Elm and React. Don't need to be the fastest on the market but can't be appallingly slow either.

Will be in the next release when this PR is merged:
https://github.com/PurpleKingdomGames/tyrian/pull/99

Done! Went out with 0.5.0.

repo: PurpleKingdomGames/tyrian


text:
is it posible to make it so that i can have a button to remove all monsters from the map?

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the new feature you'd like
A clear and concise description of what you want to happen.

I would like to use this for a tv table.
for easy set up it would be nice to have a button to turn on and off monster grafics on the map, we will just use it for easy setup off standees. and maby a rotat map and zoom to make the maps fit better the screen and an standees.


text:
Inverse Abel's transform with already-integrated data

I have been working on a plasma physics-based experiment and dealing with some flux recordings arranged as a matrix of n observations (rows) and m channels (columns). Starting from each row, which consists of m line integrals along pre-defined lines of sight, whose spatial orientation is known in terms of polar coordinates (radius and angle), I would use the PyAbel package to reconstruct the original, spatial 2D profile from these line integrals. Is it possible?
Just to give you an idea, this is a piece of code I wrote from scratch:
from pathlib import Path
import numpy as np
import matplotlib.pyplot as plt
import os
import abel
# Upload data
rootDirectory = Path(os.path.dirname(os.path.realpath(__file__))).parent
shot          = '42830'
fileName      = '\Shot_' + shot + '_Ordered_By_Impact_Parameter_Filtered_68_Channels.csv'
fullPath      = str(rootDirectory) + '\Results\Files' + fileName
wholeData     = np.loadtxt(fullPath, delimiter = ",")
nRows, nCols  = np.shape(wholeData)
# Mean by columns
nSamples     = 10000
if nSamples > nRows:
    nSamples = 500
selectedData = wholeData[0:nSamples,]
inputData    = np.mean(selectedData, axis = 0)
# Run the inversion
outputData = abel.direct.direct_transform(inputData, direction = "inverse", correction = True)
# Visualisation
plt.plot(outputData)
plt.show()

Apart from trivial operations for data loading and selection (I do not want to use all the rows momentarily, therefore I decide to pick just a reduced number of rows and average them so that inputData is the 1D input vector for the algorithm), I do not know whether the transformation is properly executed. Consider that the 1D array that the transformation outputs ought to be "rotated" around its axis to create a surface.
If you may help to figure this out, I would really appreciate (so far, I have not found anything useful in the documentation, but that will be just my fault). Thanks in advance!

Hi @spinang!
I'm a little confused about exactly what your data corresponds to. Is there a previous paper that shows how the data is collected, or can you provide a drawing or something? Is the experiment indeed taking a projection of a 3D object as shown in this figure: https://user-images.githubusercontent.com/1107796/48970223-1b477b80-efc7-11e8-9feb-c614d6cadab6.png It sounds like the data is perhaps recorded in polar coordinates instead of cartesian, which would differ slightly from that figure.
For your example code, we would need the data file to really play with it. If it's okay with you, perhaps you can upload that too so that we can run your example. You could use a Github Gist   to upload the file and then include the link here. Or, if you'd rather not share your experimental data, prepare some sort of basic example that we can look at.

Hello @DanHickstein, thanks for replying me so soon.
I am sorry if my comment was unclear, let me try to explain it better. As far as I understood, to perform the inverse Abel's transform the package relies on 2D or even 1D profiles, such as Gaussian curves as shown in many examples throughout the documentation. The problem I have been trying to solve is slightly different, because the data I have at disposal are ALREADY line integrals through an unknown, spatial profile I have to rebuild. To help you to understand, I have reported a picture that shows the scenario of my interest:

Each chord is a line projection fully identified by an angle and a radius (or impact parameter) and each column within my data set is essentially a chord (i.e., each of the m columns). Thereby, each pair (row, column) determines the value of a line integral at a given time, for a given chord. What I would like to do is to feed these rows into the algorithm for Abel's inversion and obtain the spatial profile again or, at least, a planar representation that ought to be symmetrically "rotated" around its axis to get the final surface. I am sorry I cannot provide you the data, because they are reserved for ongoing research purposes at the moment.
Please let me know if there are further details you need and I will try to give you them at the earliest opportunity.

@spinang note in the PyAbel example image, the 3D distribution has cylindrical symmetry. The 2D projection is the integrated intensity through the 3D distribution along the x-axis. i.e. each pixel of the 2D projection is similar to the chord measurement that you describe.

Where is the cylindrical symmetry axis of your distribution? Are your measurements relative to a fixed position of the symmetry axis?

@spinang,
Does your object have cylindrical or spherical symmetry? At least cylindrical symmetry is a requirement of the Abel transform.
Also, for each time, you say that you have many chords (projections at a specific radius and angle). In our typical situation, we also have projections, but they are all at the same angle and at various, evenly spaced radii.

Hi @spinang, I hope that you found a solution to your problem. I'm going to close this issue for now for bookkeeping purposes. If you'd like to continue the discussion, just post here and I'll re-open the issue, or start a new Issue with a new question. I hope you are enjoying using PyAbel!

Hi @spinang, I hope that you found a solution to your problem. I'm going to close this issue for now for bookkeeping purposes. If you'd like to continue the discussion, just post here and I'll re-open the issue, or start a new Issue with a new question. I hope you are enjoying using PyAbel!

authors: DanHickstein spinang stggh

repo: PyAbel/PyAbel


text:
[EVENT] 19 Feb 2025 - Contributing to scikit-learn hack night @ WeWork

Head organizer: Maren
Support organizer: Jessica, Bita
Slides/Moderation: Maren, Adrin, Guillaume, Stefanie, Tamara
Mentor support: Maren
Location: Warschauer Pl. 11-13, 10245 Berlin
MONTH BEFORE

[x] Define Mentors
[ ] Announce event with mentors, location, gender policy, photo policy on meetup page
[x] Define hosts & collect host information
[ ] Send Host guidelines email @adrinjalali
[ ] Organise Food/ drinks @adrinjalali
[ ] Share event on social media when announced

TWO WEEKS BEFORE

[ ] Re-share event on social media
[ ] Check with mentors about installation instructions/reading material and a list of (beginner friendly) issues to work on
[ ] Update meetup announcement with agenda, networking breaks, if snacks or drinks will be available
[ ] Check-in with hosts and ask if support is needed for reception

WEEK BEFORE

[ ] Remind attendees to install requirements with comment and/or message on meetup
[ ] Send coaches the workshop/relevant material

WEEK OF THE EVENT

[ ] Ask host if attendees list is needed and/or special location directions
[ ] Double check with host: microphone (if needed), soft drinks, power plugs, internet, tables and chairs
[ ] Send to host to print PyLadies arrow signs
[ ] Print [feedback forms](feedback forms)
[ ] Prepare introduction slides past example

DAY OF THE EVENT
(arrive 30-60 minute before event starts)

[ ] Bring swag (stickers, T-shirts, other promotion material)
[ ] Check projector, microphone, table setup, power extensions, recording if available
[ ] Support mentor(s) to test equipment
[ ] Stick PyLadies signs to guide attendees the location
[ ] Hang up or put out print outs with the WIFI (or find a similar solution)
[ ] Manage reception, give name tags if available

DURING THE EVENT

[ ] Do introduction and Community announcements
[ ] Take photos of all the speakers and audience
[ ] Tweet about it (or after the event with photos)

AFTER THE EVENT

[ ] Tweet after event (if not done during the event)
[ ] Upload photos to google drive (you need to be part of the google group to access this)
[ ] Open PR with resources to this repository
[ ] Email sponsors & host to thank them
[ ] Copy feedback forms to feedback spreadsheet
[ ] Adjust guides if valuable feedback came up

I still need to check with WeWork regarding drinks.

authors: adrinjalali marenwestermann

repo: PyLadiesBerlin/community-organisation


text:
Update logic for electrical demand in sector studies

Feature Request
More of an issue for the sector coupling studies, but when applying demand it can be hard to determine what is actually included in the electrical demand. For example, when applying the EFS electrical demand, it includes future projections for meeting transport and heating through electrification options. In sector coupling studies, this demand should be treated separately, as the model should be choosing how to meet it.
Suggested Solution
May be nice in the demand module to set up a datastructure that can filter by sector and demand type. Then the "business" logic can be how to add these demands together for electrical vs. sector studies.
This probably deserves a bigger discussion tho! :)
Additional Info
No response

Definitely... you'll see a line in my code for EFS demand data where I throw out all the great data on end-uses:
https://github.com/PyPSA/pypsa-usa/blob/1ef05ce3625de68512b2321f187caceec03780ce/workflow/scripts/add_electricity.py#L842C1-L854C1

repo: PyPSA/pypsa-usa


text:
PyThaiNLP 2.3 change log

Schedule

First development release: 16 March 2021
Beta release: 23 March 2021
Production release: 30 March 2021

Docs: https://pythainlp.github.io/dev-docs/index.html
See 2.3 Milestone.
Deprecation and other API changes

NER change a ThaiNER model (from ThaiNER 1.4 to ThaiNER 1.5). If you need use ThaiNER 1.4 model, You can use version in ThaiNameTagger class. pythainlp.tag.named_entity.ThaiNameTagger(version: str = '1.4') (Docs: https://pythainlp.github.io/dev-docs/api/tag.html#pythainlp.tag.named_entity.ThaiNameTagger)

Tokenizer

#484 Add: model option for attacut.tokenize()
#502 Add: corpus.util.revise_wordset() to revise tokenization dictionary
#503 Add: NERCut tokenization engine

Corpus

License change:

All corpora, datasets, and documentation created by PyThaiNLP project are now released under Creative Commons Zero 1.0 Universal Public Domain Dedication License (CC0).
All language models created by PyThaiNLP project are released under Creative Commons Attribution 4.0 International Public License (CC-by).

#449 Fix: remove instances with [ or ] from etcc.txt
#467 Add: corpus.common.provinces() can now return romanized names
#476 Add: thai_family_names() to get a set of Thai family names
#487 Fix: thailand_provinces_th.csv not found issue
#492 Fix: remove erroneous AITT tag from ORCHID to UD table -- thanks @c4n for the fix

POS Tagger

#464 Add: LST20 language model for part-of-speech tagging
#468 Add: port PerceptronTagger from NTLK. POS tagging no longer needs NLTK for dependency.
#478 Update: ORCHID POS tags documentation

Name Entity Tagging

#526 Update ThaiNER 1.4 to ThaiNER 1.5
#538 Add ThaiNameTagger version and add ThaiNER 1.4 support

Transliterate

#485 Fixed Romanize failed in some examples
#511 Add Thai W2P (Thai Word-to-Phoneme converter)

Text Summarize

#523 Add mT5 text summarize to pythainlp.summarize

Chunk parser

#524 Add pythainlp.tag.chunk

Util

#481 Fix: remove_repeat_vowels() bug that remove spaces between different vowels
#483 Add: add remove() method to remove a word from a trie -- thanks @korakot
#490 Fix: thai_strftime() - normalize output for unsupported directive (running in glibc and musl should produce the same output)
#512 Add: emoji_to_thai() to convert emoji to Thai description -- thanks @ppirch for the development
#513 Add: thai_keyboard_dist() to calculate euclidean distance between two characters according to their location on a Thai keyboard layout -- thanks @ppirch for the development

Update Schedule

authors: bact wannaphong

repo: PyThaiNLP/pythainlp


text:
bug: (potential) tokenization of ๆ

Description
When tokenizing a sentence with ๆ, I found an example where it doesn't become a token, but instead is joined with left and right symbols.
I can't figure out whether this is a linguistic feature or an actual bug. Could you please point out whether this is a proper word and so should be a proper token?
Here is the example:
>>> word_tokenize("ละตำแหน่งผู้อำนวยการโครงการกลุ่มบริษัทเมื่อเร็ว ๆ นี้ คุณ Mr. John ได้ตัดสินใจลาออกจาก The Company", keep_whitespace=False)
['ละ',
 'ตำแหน่ง',
 'ผู้อำนวยการ',
 'โครงการ',
 'กลุ่ม',
 'บริษัท',
 'เมื่อ',
 'เร็ว ๆ นี้',  # THIS TOKEN
 'คุณ',
 'Mr',
 '.',
 'John',
 'ได้',
 'ตัดสินใจ',
 'ลา',
 'ออกจาก',
 'The',
 'Company']

Here is a counter-example, where it works as (I) expected:
>>> word_tokenize("หลังจากที่ดำรงตำแหน่งกรรมการฝ่ายปฏิบัติการของกลุ่มบริษัท ๆ นี้ คุณ Mr. John ได้ตัดสินใจลาออกจาก The Company", keep_whitespace=False)
['หลังจากที่',
 'ดำรงตำแหน่ง',
 'กรรมการ',
 'ฝ่าย',
 'ปฏิบัติการ',
 'ของ',
 'กลุ่ม',
 'บริษัท',
 'ๆ',  # TOKEN BY ITSELF
 'นี้',
 'คุณ',
 'Mr',
 '.',
 'John',
 'ได้',
 'ตัดสินใจ',
 'ลา',
 'ออกจาก',
 'The',
 'Company']

Expected results
I was expecting ๆ to always be a token by itself, but I lack knowledge in Thai to be sure about that.
Current results
Instead it forms part of a token with inner whitespaces:  เร็ว ๆ นี้.
Steps to reproduce
from pythainlp import word_tokenize

word_tokenize("ละตำแหน่งผู้อำนวยการโครงการกลุ่มบริษัทเมื่อเร็ว ๆ นี้ คุณ Mr. John ได้ตัดสินใจลาออกจาก The Company", keep_whitespace=False)

PyThaiNLP version
3.1.1
Python version
3.8.4
Operating system and version
Ubuntu 22.04.1 LTS
More info
No response
Possible solution
No response
Files
No response

Thank you for reporting. It's not a bug because "เมื่อเร็ว ๆ นี้" is mean "recently". If you don't want the potential (ๆ), you can use custom_dict.
from pythainlp.util import Trie
from pythainlp.tokenize import word_tokenize
from pythainlp.corpus import thai_words # load the dict

list_thai_words_without_potential = [i for i in list(thai_words()) if "ๆ" not in i]
thai_words_without_potential = Trie(list_thai_words_without_potential)

# use custom_dict from https://pythainlp.github.io/docs/3.1/api/tokenize.html#pythainlp.tokenize.word_tokenize
word_tokenize("ละตำแหน่งผู้อำนวยการโครงการกลุ่มบริษัทเมื่อเร็ว ๆ นี้ คุณ Mr. John ได้ตัดสินใจลาออกจาก The Company", keep_whitespace=False, custom_dict=thai_words_without_potential)

Thai writing use "ๆ" as the repetition character for repetition of the previous word but It can change the meaning of word of use it. http://www.thai-language.com/ref/special-symbols

So it means it's totally valid to sometimes have "ๆ" as a token and sometimes as part of another. Thanks for the clarification.
Related to this, would it mean anything different if "ๆ" was preceded by two white spaces or a longer white space? In the tokenizer, for the case of "recently", it causes "ๆ" to be split into a separate token.

So it means it's totally valid to sometimes have "ๆ" as a token and sometimes as part of another. Thanks for the clarification.
Related to this, would it mean anything different if "ๆ" was preceded by two white spaces or a longer white space? In the tokenizer, for the case of "recently", it causes "ๆ" to be split into a separate token.

No. Today, Most Thai people in social network doesn't likes use any white space for "ๆ"  but the Royal Society of Thailand still recommend use a white spaces before and after used "ๆ".

If you see "เมื่อเร็วๆนี้"/"เมื่อเร็ว  ๆนี้"/"เมื่อเร็วๆ  นี้" then it has the same meaning as "เมื่อเร็ว ๆ นี้". All are same meaning. The longer white space doesn't change the meaning.

Thanks a lot, Wannaphong. This is very informative.
So despite all those forms meaning the same thing, the reason they don't get tokenized the same way is because of the dictionary?
>>> word_tokenize("เมื่อเร็วๆนี้", keep_whitespace=False)
['เมื่อ', 'เร็ว', 'ๆ', 'นี้']

>>> word_tokenize("เมื่อเร็วๆ นี้", keep_whitespace=False)
['เมื่อ', 'เร็ว', 'ๆ', 'นี้']

>>> word_tokenize("เมื่อเร็ว ๆนี้", keep_whitespace=False)
['เมื่อ', 'เร็ว ๆ', 'นี้']

>>> word_tokenize("เมื่อเร็ว ๆ นี้", keep_whitespace=False)
['เมื่อ', 'เร็ว ๆ นี้']

Thanks a lot, Wannaphong. This is very informative.
So despite all those forms meaning the same thing, the reason they don't get tokenized the same way is because of the dictionary?

Yes, newmm is a dictionary-based tokenizer. You can custom the dictionary or try the deep learning method.
This is the all open source resource for Thai: https://nlpforthai.com/

Thanks again. Appreciate the help.

authors: kepler wannaphong


text:
Inconsistent behaviour for dataloader_idx

Motivation: Very inconsistent behaviour
I'm having a varying number of validation data loaders, depending on the dataset I'm evaluating. For some datasets I have only 1 validation dataloader, while for other datasets I have 5 validation dataloaders.
I want to use the same model (LightningModule class), but the function definition validation_step is not compatible when having 1 or multiple dataloaders. Currently, the positional parameter dataloader_idx is passed only when there are multiple dataloaders (see documentation). Consequently, this forces developer to create custom validation code for when the positional parameter dataloader_idx is received.
Currently, the code should look as below, which is not compatible
# One dataloder
def validation_step(self, batch, batch_idx)

# Multiple dataloaders; this is not compatible with the above because the parameter `dataloader_idx` is passed as a positional argument and can't be received using `**kwargs`
def validation_step(self, batch, batch_idx, dataloader_idx)

Proposed refactor
Make the parameter dataloader_idx a keyword argument and enable the user to receive it via **kwargs for when it's needed.
# One dataloder (leave it as now)
def validation_step(self, batch, batch_idx):

# Multiple dataloaders
def validation_step(self, batch, batch_idx, **kwargs):
    print(kwargs['dataloader_idx']) # 0, 1, 2, 3, ...

cc @justusschock @awaelchli @akihironitta @rohitgr7 @carmocca @borda @ninginthecloud @daniellepintz

Never mind, I found a much simpler solution fo rmy usecase. I defined the function as:
def validation_step(self, batch, batch_idx, dataloader_idx=0)

which works well when there are 1 or multiple data loaders.

repo: PyTorchLightning/pytorch-lightning


text:
Batch Size Tuner is unable to free memory after OOM

🐛 Bug

When using the batch size tuner, torch.cuda.empty_cache() does not free the memory that pytorch tried to allocated before going OOM. This results in the batch size tuner leaving the device memory full.
Unfortunately, I have limited time and the Boring model would require too much work to replicate the bug with.
Environment

CUDA:

GPU:

GeForce GTX 1060 6GB

available:         True
version:           10.2

Packages:

numpy:             1.19.2
pyTorch_debug:     False
pyTorch_version:   1.8.1
pytorch-lightning: 1.2.8
tqdm:              4.55.1

System:

OS:                Linux
architecture:

64bit
ELF

processor:
python:            3.8.6
version:           #1 SMP PREEMPT Mon Dec 21 22:00:46 UTC 2020

PyTorch Version (e.g., 1.0): Also does not work with 1.7.1

@half-potato mind check our RC from yesterday? pip install pytorch-lightning==1.3.0rc0

Version: pytorch-lightning==1.3.2
Sure, it doesn't fail to allocate memory anymore, but it also doesn't actually tune the batch size. It doesn't ever run
trainer.reset_train_dataloader(model)

As a result, it never runs OOM. Putting this line back into _adjust_batch_size results in the same problem, where the memory isn't freed.
I found this issue on pytorch: https://github.com/pytorch/pytorch/issues/18853
It appears that it could be a driver issue.

authors: Borda half-potato


text:
Bugfix/2956 tpu distrib backend fix

What does this PR do?
sets distributed_backend to 'tpu' when tpu_cores is set
Fixes #2956
Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together? Otherwise, we ask you to create a separate PR for every change.
[x] Did you make sure to update the documentation with your changes?
[x] Did you write any new necessary tests?
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] If you made a notable change (that affects users), did you update the CHANGELOG?

PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

then we probably can drop the tpu annotation in tests...

authors: Borda lezwon


text:
Fix build by pinning pydantic version

This PR:

[x] Closes #401.
[ ] Adds and passes relevant tests.
[ ] Has well-formatted code and documentation.

Notes:

It is essential that you add a test when making code changes.
This keeps the code coverage level up, and helps ensure the changes work as intended.
When fixing a bug, you must add a test that would produce the bug in the master branch, and then show that it is fixed with the new code.
New code additions must be well formatted. Changes should pass the pre-commit workflow, which you can set up locally using pre-commit.
Docstring additions must render correctly, including escapes and LaTeX.

Should fix the documentation builds (hopefully) by pinning pydantic to 2.4.2 for now.

The RTD issue seems unrelated (and likely caused by some issue with the virtualenv? I need to investigate further).

repo: PyVRP/PyVRP


text:
Can't yank over other text

This is a repercussion of #26. It means that things like Vp (to substitute a line in normal-state) no longer work.

In fact this is true of yanking in general.

Unfortunately, I can't seem to reproduce this...

I'm going to say this appears to be fixed.

There is another issue that results from this. Will need to reproduce.

This is specific to evil-mode visual state pastes

repo: PythonNut/emacs-config


text:
Get most recent mined tx's and events related to a from/to address we are interested in

Allow user to add a from/to address, event they want to watch for, and preferred place of notification
Parse most recent mined block transactions and their related events
Sort transactions with a from/to that we are interested in
Get all events related to the transactions we are interested in
Send from/to/txHash&&relatedEvents to user on preferred place of notification

Use Case 1:

user wants TG notifications for every tx that comes from their wallet or any other address on chain


text:
move TODOs to issues

I think it's better to keep "TODO"s in one place.

Agreed. "TODO"s will go away over the next week or so; I am starting to write the extended abstract and in doing so will finalize some missing todo items

Fixed in https://github.com/QAOAKit/QAOAKit/commit/506ad0f814a056db488ce1406b6c1478a98be367

authors: marwahaha rsln-s

repo: QAOAKit/QAOAKit


text:
NodeJS inatallationerror

TASK [excute shell script downloaded] **************************************************************************************************************************************
[WARNING]: Consider using 'become', 'become_method', and 'become_user' rather than running sudo
fatal: [ip-172-31-21-1.us-east-2.compute.internal]: FAILED! => {"changed": true, "cmd": ["sudo", "bash", "/home/ansible/nodesetup/nodesource_setup.sh"], "delta": "0:00:00.008359", "end": "2018-10-30 15:41:48.460441", "msg": "non-zero return code", "rc": 127, "start": "2018-10-30 15:41:48.452082", "stderr": "bash: /home/ansible/nodesetup/nodesource_setup.sh: No such file or directory", "stderr_lines": ["bash: /home/ansible/nodesetup/nodesource_setup.sh: No such file or directory"], "stdout": "", "stdout_lines": []}
to retry, use: --limit @/home/ansible/Nodejs/node.retry
PLAY RECAP *****************************************************************************************************************************************************************
ip-172-31-17-125.us-east-2.compute.internal : ok=2    changed=1    unreachable=0    failed=0
ip-172-31-21-1.us-east-2.compute.internal : ok=5    changed=2    unreachable=0    failed=1
But file available with below screenshot
ansible@ip-172-31-43-101:~$ curl -sL https://deb.nodesource.com/setup_8.x -o nodesource_setup.sh
ansible@ip-172-31-43-101:~$ ls
Nodejs  apache.yml  hosts  nginx.retry  nginx.yaml  nginx.yml  nodesource_setup.sh  playbooks
ansible@ip-172-31-43-101:~$ cd Nodejs/
ansible@ip-172-31-43-101:~/Nodejs$ ls
README.md  inventory  node.retry  node.yml
ansible@ip-172-31-43-101:~/Nodejs$ ansible-playbook -i inventory node.yml

@kmahesh121785
Upload your complete playbook. (zip)

Node.yml

hosts: all
become: yes
tasks:

name: update packing
apt:
update_cache: yes

node JS specific setting (url :https://www.digitalocean.com/community/tutorials/how-to-install-node-js-on-ubuntu-16-04)

hosts: app
become: yes
vars:
folderpath: /home/ansible/nodesetup
tasks:

name: creating a directory
file:
path: "{{ folderpath }}"
state: directory
mode: 0755
name: Download node js on ubuntu
command: "curl -sL https://deb.nodesource.com/setup_8.x -o {{ folderpath}} nodesource_setup.sh"
name: excute shell script downloaded
command: "sudo bash {{folderpath}}/nodesource_setup.sh"
name: Installing Nodejs
apt:
name: nodejs
state: present
========================================================
Inventory

[web]
ip-172-31-17-125.us-east-2.compute.internal
[app]
ip-172-31-21-1.us-east-2.compute.internal

It worked fine for me. NodeJS v8.12.0 installed
YML file

ansible-playbook

NodeJS installed in app

repo: QT-DevOps/DevOpsIssues


text:
Trying to call QA_fetch_get_stock_day method

Hello,
I have just joined the Quantaxis community and I would like to make my first method call.
When trying to execute this command QA.QAFetch.QATdx.QA_fetch_get_stock_day('tdx', '000001', '2017-01-01', '2017-01-02') I get the first error of unexpected timeout argument in the method connect() in QUANTAXIS\QAFetch\QATdx.py
Then I removed the timeout argument and got this error:
with api.connect(ip, port):

AttributeError: enter
Can someone help me please? I'm not a Chinese speaker so would you mine to write me in English?
Thank you

all right ...
the reason for timeout is a pr which i made for pytdx repo, in that pr, i add a timeout parameter, which is already updated  in pytdx, however the tushare package get a early version of pytdx, and made it inside..
so, here is the solution
pip uninstall pytdx

pip install pytdx

the  AttributeError maybe a bad response if u re not in chinese , so firstly re-install the pytdx and try it again, QUANTAXIS will test the speed of best sever for U

Thank you very much! That works fine for me and servers are responding
I uninstalled and re-installed pytdx package and changed my wifi connection too
Kind regards

repo: QUANTAXIS/QUANTAXIS


text:
Animation on data change?

Hey guys, love the library, could you please add animation when data changes or new properties are added? Would be very nice, thank you!

You can try laue https://github.com/QingWei-Li/laue

Here's a hack that worked for me:
I assign a key to the vue-trend instance and update it when the data changes in order to redraw the chart.  This is a good write-up on forcing a component to render again in Vue.

authors: MishUshakov QingWei-Li thaddeusm

repo: QingWei-Li/vue-trend


text:
question about early stopping

Thank you for your marvelous work!
Did you use a validation set and early stopping to select the best-performing checkpoint? If so, how do you ensure that the budget reaches the target budget?
Best,

Hi, thanks for your question. We did not apply early stopping, and evaluate the model during the final fine-tuning stages, when AdaLoRA reaches the target budget and fix it. The checkpoint can be selected during the final fine-tuning stage, i.e. after total_step-final_warmup steps. Hope this can answer your questions.

Do you select the best checkpoint in the final fine-tuning stage?

authors: A11en0 DopamineLcy QingruZhang

repo: QingruZhang/AdaLoRA


text:
do a try for Qiskit direct timestamps

Qiskit direct has a different format for its timestamps.  Since getting access to that system is tricky, here we just do a try, and substitute the now time for the timestamp if we hit a ValueError

There is a better way here.

repo: Qiskit-Partners/mthree


text:
[Stable] Drop support for Python 3.6 (#121)

Summary
Backport of #121
Details and comments

Pull Request Test Coverage Report for Build 2580394845

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 82.735%

Totals

Change from base Build 2580039099:
0.0%

Covered Lines:
714

Relevant Lines:
863

💛  - Coveralls

authors: coveralls manoelmarques

repo: Qiskit/qiskit-finance


text:
Docs: Migration guide should use Qiskit Runtime

The migration guide uses from qiskit.primitives import Sampler, which uses a local statevector simulator. But people migrating their Qiskit Runtime custom programs would not want to use a local simulator. They'd want to use a real IBM Quantum backend (otherwise they can just run locally on their laptop).

Thanks for the ping @jyu00 🙏
We will take a look

repo: Qiskit/qiskit-serverless


text:
%qiskit_backend_overview returns ZeroDivisionError

Information

Qiskit Terra version: 0.18.3
Python version: 3.8.10
Operating system: macOS Big Sur Version 11.6 (Though running in Quantum Lab also produces this error)

What is the current behavior?
Running the following code results in a ZeroDivisionError:
from qiskit import IBMQ
import qiskit.tools.jupyter
%matplotlib inline

%qiskit_backend_overview

This is the full stack trace returned:
---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)
<ipython-input-5-e9e9700c904d> in <module>
      3 get_ipython().run_line_magic('matplotlib', 'inline')
      4
----> 5 get_ipython().run_line_magic('qiskit_backend_overview', '')

~/opt/anaconda3/envs/qiskit-env/lib/python3.7/site-packages/IPython/core/interactiveshell.py in run_line_magic(self, magic_name, line, _stack_depth)
   2305                 kwargs['local_ns'] = sys._getframe(stack_depth).f_locals
   2306             with self.builtin_trap:
-> 2307                 result = fn(*args, **kwargs)
   2308             return result
   2309

</Users/Matthew.Stypulkoski@ibm.com/opt/anaconda3/envs/qiskit-env/lib/python3.7/site-packages/decorator.py:decorator-gen-134> in qiskit_backend_overview(self, line)

~/opt/anaconda3/envs/qiskit-env/lib/python3.7/site-packages/IPython/core/magic.py in <lambda>(f, *a, **k)
    185     # but it's overkill for just that one bit of state.
    186     def magic_deco(arg):
--> 187         call = lambda f, *a, **k: f(*a, **k)
    188
    189         if callable(arg):

~/opt/anaconda3/envs/qiskit-env/lib/python3.7/site-packages/qiskit/tools/jupyter/backend_overview.py in qiskit_backend_overview(self, line)
     44         backend_title = widgets.HTML(value=_value, layout=widgets.Layout(margin="0px 0px 0px 0px"))
     45
---> 46         build_back_widgets = [backend_widget(b) for b in unique_hardware_backends]
     47
     48         _backends = []

~/opt/anaconda3/envs/qiskit-env/lib/python3.7/site-packages/qiskit/tools/jupyter/backend_overview.py in <listcomp>(.0)
     44         backend_title = widgets.HTML(value=_value, layout=widgets.Layout(margin="0px 0px 0px 0px"))
     45
---> 46         build_back_widgets = [backend_widget(b) for b in unique_hardware_backends]
     47
     48         _backends = []

~/opt/anaconda3/envs/qiskit-env/lib/python3.7/site-packages/qiskit/tools/jupyter/backend_overview.py in backend_widget(backend)
    200                             sum_cx_err += param["value"]
    201                             num_cx += 1
--> 202         avg_cx_err = round(sum_cx_err / (num_cx), 4)
    203
    204     cx_widget = widgets.HTML(value=f"<h5>{avg_cx_err}</h5>", layout=widgets.Layout())

ZeroDivisionError: division by zero

Steps to reproduce the problem
Run the code snippet above
What is the expected behavior?
The backend_overview widget should not error out and should return the expected backend overviews.

Thanks for the report.  Hopefully this should be fixed by #7260 - if you're able to test that out, it'd be great, because by default I don't have access to any of the problematic machines, and our testing infrastructure is a bit lacking in that area.

By the way (and this has no impact on the bug you're reporting), you may want to check your Jupyter environment is what you expect - you said your Python version is 3.8.10, but your packages are being imported from a Python 3.7 environment.  You may just have had the wrong environment activated, or you may not have Jupyter installed in the environment you meant, so when you run it, it pulls from a different environment.

authors: Matt-Stypulkoski jakelishman

repo: Qiskit/qiskit-terra


text:
Fix for size mismatched in initializer instruction

Fixes #2372
Each instruction is in charge of testing how many parameters are expected. This PR fixes that and add tests.

This looks good. The second test doesn't seem to be checking anything new though (there's already a test to see if initialize works on a register)

Both tests fail in master without this patch. Which is the test that does the same?

Both tests fail in master without this patch. Which is the test that does the same?

I know. I'm just saying i don't understand what coverage test#2 adds on top of test#1, they do the same thing. If you're testing that initialize can be applied to a register, there's already another test for that too.

Oh! I see what you mean. It was because my first fix did not consider the length of the register. But it is true that there is not difference in the fix that I pushed. Removed. Thanks.


text:
Exclamation points

What Changes Were Made?
Edited to make tone less conversational, replaced idioms with more formal English, made more concise, fixed spelling errors/typos and broken math notation, adjusted punctuation etc. to make more readable
How Was This Tested?
Reloaded notebook in browser and read through my own changes.
Anything Else We Should Know

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@frankharkins Hey Frank -- I see you pushed some changes a couple days ago while I was working on this page, and I don't want to screw up your formatting fixes in anticipation of moving to IQX.  Can I look at this with you at some point and figure out how to mirror your changes in my PR, if possible? I am scared stiff of trying to hack-edit ipynb files...!!

Hi Abby, thanks for your help! The formatting changes were just to do with the table of contents (if it exists) and making sure there are newlines between the text and the display equations. Everything seems to be fine so I've merged your changes with the master branch. Hope that's okay.

authors: abbycross claassistantio frankharkins

repo: Qiskit/qiskit-textbook


text:
sidebar title aka fix #354

fixing dead link for c-sidebar__title.
this fixes #354

Description of Issue (if Applicable)
Fixes #your_issue_number_here
What Changes Were Made?
How Was This Tested?
Please provide any screenshots if applicable.
Anything Else We Should Know

good spot, thank you

authors: frankharkins omarcostahamido


text:
Oxidize QuantumCircuit._data and intern CircuitInstruction args

Summary
Introduces a new list-like Rust data typeCircuitData, used to more efficiently store a QuantumCircuit's instruction listing in memory. This is used along with another new Rust type InternContext, which serves as a cache for argument lists that use the same sequence of numeric bit identifiers.
The basic idea is that when a CircuitInstruction instance is appended to QuantumCircuit, the underlying CircuitData stores just a reference to its operation on the Python heap and two u32 IDs (handles into the InternContext) which correspond to its qubits and clbits argument lists. When CircuitData elements are accessed (e.g. via QuantumCircuit._data), they get converted back to CircuitInstruction instances.
Details and comments
These changes leave the QuantumCircuitData wrapper entirely in place, with a few internal modifications to side-step implementing things like __rmul__ for the Rust-side CircuitData.
The InternContext deals in terms of bit indices (not Python references), so it's naturally able to share argument lists across circuits, and it doesn't distinguish between qubit and clbit arg lists. Its only limitation is really the number of unique argument sequences it can store, which right now is 2^32 since we're using a slotted approach with u32 IDs.
At present, new QuantumCircuit instance manage their own InternContext, and copies of a circuit share the context of the original. In theory, we could use another mechanism to share the same InternContext across (all | some) new circuits (e.g. using a Python singleton), but that's probably only worth exploring if we discover that memory pressure across circuits is a big bottleneck for users down the line.
Intern context implementation
When an argument list is interned (via InternContext::intern(arg_list: Vec<BitType>)-> IndexType), the provided argument list is looked up in a mapping of arg list to slot ID, a u32. If the mapping already exists, the returned slot ID identifies a slot which already contains the argument list corresponding to arg list. The number of uses (also a field of the slot) is incremented. If the mapping does not exist, the next available slot is claimed, the arg list is moved into it, and the new slot's use count is set to 1.
An interned argument list is retrieved via its slot ID (InternContext::lookup(slot: IndexType) -> &Vec<BitType>).
When a client of InternContext knows that it no longer needs a particular use of a slot, it can call InternContext::drop_use(slot: IndexType) to decrement the use count, unallocating the slot if it is no longer in use.
The (likely) only client of InternContext is CircuitData, which has been written with care to drop intern uses as CircuitInstructions are removed from it, and on its own destruction.
Memory profiling
I profiled circuit construction with memray of a circuit with about 5 million parameter-less gates and found that peak memory use was reduced by about 400 MiB (from 1.7 GiB to 1.3 GiB). With #10314 applied, the same circuit comes down to just 192 MiB peak memory use (most of our memory pressure comes from operation instances, with argument lists being the second worst offender).
Todo

[ ] Memory profiling for common operations on large circuits. I've only profiled circuit construction so far.
[ ] Performance profiling.
[ ] Remove instances of us copying the contents of QuantumCircuit._data into Python lists in various places.
[x] Run ASV.
[x] Rust-side unit testing for InternContext.
[x] ~Handle case of intern context full.~ => likely not necessary with 2^32 slots.

Thanks to @mtreinish, we now have the ASV output for this branch when compared to main, which shows no significant differences.
Benchmarks that have stayed the same:

       before           after         ratio
     [01bb111c]       [1d63a40a]
     <main>        <oxidize-qc-data>
       8.31±0.1ms       8.73±0.2ms     1.05  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_through_pulse_gate(31)
       18.3±0.7ms       18.6±0.9ms     1.02  quantum_volume.QuantumVolumeBenchmark.time_ibmq_backend_transpile(3, 'translator')
         84.9±1ms         86.3±2ms     1.02  circuit_construction.CircuitConstructionBench.time_circuit_copy(1, 32768)
      2.73±0.01ms      2.77±0.02ms     1.02  pulse.schedule_construction.EchoedCrossResonanceConstructionBench.time_full_scratch
         901±40μs         914±60μs     1.01  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_through_pulse_gate(3)
         24.3±2ms         24.6±1ms     1.01  circuit_construction.CircuitConstructionBench.time_circuit_copy(2, 8192)
      2.58±0.02ms      2.61±0.02ms     1.01  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_parameterized_subroutine(11)
        112±0.4μs        113±0.4μs     1.01  circuit_construction.CircuitConstructionBench.time_circuit_construction(5, 8)
      7.11±0.07ms      7.20±0.09ms     1.01  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_parameterized_subroutine(31)
       26.3±0.3ms       26.6±0.8ms     1.01  circuit_construction.CircuitConstructionBench.time_circuit_copy(5, 8192)
         644±40μs         651±20μs     1.01  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_single_schedule(3)
          223±2ms          226±2ms     1.01  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_qv_14_x_14(1)
      3.00±0.05ms      3.03±0.02ms     1.01  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_through_pulse_gate(11)
          780±5μs          787±5μs     1.01  pulse.schedule_construction.EchoedCrossResonanceConstructionBench.time_assign_later
          309±1ms          312±3ms     1.01  circuit_construction.CircuitConstructionBench.time_circuit_construction(14, 32768)
       13.7±0.2ms      13.8±0.09ms     1.01  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_through_pulse_gate(51)
       56.3±0.6μs       56.7±0.9μs     1.01  circuit_construction.CircuitConstructionBench.time_circuit_copy(8, 8)
          105±1μs          106±2μs     1.01  circuit_construction.CircuitConstructionBench.time_circuit_construction(2, 8)
          139±1ms          140±1ms     1.01  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm_backend_with_prop(0)
          423±3μs          425±2μs     1.01  circuit_construction.CircuitConstructionBench.time_circuit_copy(5, 128)
      2.64±0.02ms      2.65±0.03ms     1.01  pulse.schedule_construction.EchoedCrossResonanceConstructionBench.time_with_call
          197±2ms          198±2ms     1.01  passes.MultipleBasisPassBenchmarks.time_basis_translator(5, 1024, ['rz', 'x', 'sx', 'cx', 'id'])
       1.28±0.01s       1.29±0.03s     1.01  circuit_construction.CircuitConstructionBench.time_circuit_construction(5, 131072)
       18.3±0.1ms       18.4±0.2ms     1.01  circuit_construction.CircuitConstructionBench.time_circuit_copy(1, 8192)
          466±4ms          468±2ms     1.00  quantum_volume.QuantumVolumeBenchmark.time_ibmq_backend_transpile(14, 'translator')
          708±5ms          711±5ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(1, 131072)
          525±2ms          527±3ms     1.00  passes.MultipleBasisPassBenchmarks.time_basis_translator(14, 1024, ['rz', 'x', 'sx', 'cx', 'id'])
      9.79±0.08ms      9.83±0.09ms     1.00  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_single_schedule(51)
      6.49±0.04ms      6.51±0.05ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_copy(14, 2048)
      1.23±0.02ms      1.24±0.03ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(2, 128)
          429±1μs          430±4μs     1.00  circuit_construction.CircuitConstructionBench.time_circuit_copy(8, 128)
         42.5±1ms         42.7±1ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(1, 8192)
          1.24±0s       1.24±0.01s     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(20, 131072)
        431±0.8μs          432±2μs     1.00  circuit_construction.CircuitConstructionBench.time_circuit_copy(14, 128)
      4.49±0.02ms      4.50±0.04ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_copy(1, 2048)
          128±2ms          129±2ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_copy(14, 32768)
      2.16±0.04ms      2.16±0.03ms     1.00  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_single_schedule(11)
       94.2±0.3μs       94.4±0.3μs     1.00  circuit_construction.CircuitConstructionBench.time_circuit_copy(14, 8)
      5.93±0.02ms      5.94±0.05ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_copy(2, 2048)
       55.7±0.3ms       55.8±0.5ms     1.00  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm(0)
       19.0±0.2ms      19.0±0.06ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(20, 2048)
          317±4ms          317±1ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(5, 32768)
       1.97±0.01s       1.97±0.01s     1.00  transpiler_levels.TranspilerLevelBenchmarks.time_quantum_volume_transpile_50_x_20(2)
          170±1ms        170±0.6ms     1.00  passes.MultipleBasisPassBenchmarks.time_basis_translator(5, 1024, ['u', 'cx', 'id'])
          665±4ms          665±4ms     1.00  passes.MultipleBasisPassBenchmarks.time_basis_translator(14, 1024, ['rx', 'ry', 'rz', 'r', 'rxx', 'id'])
          306±2ms          306±3ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(2, 32768)
        307±0.9ms          307±3ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(20, 32768)
       35.6±0.2μs       35.5±0.3μs     1.00  circuit_construction.CircuitConstructionBench.time_circuit_copy(2, 8)
       1.68±0.01s       1.68±0.01s     1.00  quantum_volume.QuantumVolumeBenchmark.time_ibmq_backend_transpile(27, 'translator')
        632±0.9ms          631±3ms     1.00  passes.MultipleBasisPassBenchmarks.time_basis_translator(20, 1024, ['u', 'cx', 'id'])
       2.86±0.1ms       2.86±0.1ms     1.00  quantum_volume.QuantumVolumeBenchmark.time_ibmq_backend_transpile(1, 'translator')
       1.28±0.01s       1.28±0.02s     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(8, 131072)
          931±8ms          929±3ms     1.00  passes.MultipleBasisPassBenchmarks.time_basis_translator(20, 1024, ['rx', 'ry', 'rz', 'r', 'rxx', 'id'])
          318±3ms          317±3ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(8, 32768)
          127±1ms          127±2ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_copy(20, 32768)
          123±2ms        122±0.4ms     1.00  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm(1)
       1.23±0.01s          1.23±0s     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(2, 131072)
         76.0±1ms       75.7±0.9ms     1.00  circuit_construction.CircuitConstructionBench.time_circuit_construction(20, 8192)
          734±4ms          730±4ms     1.00  passes.MultipleBasisPassBenchmarks.time_basis_translator(20, 1024, ['rz', 'x', 'sx', 'cx', 'id'])
      26.6±0.07μs       26.5±0.1μs     1.00  circuit_construction.CircuitConstructionBench.time_circuit_copy(1, 8)
       11.6±0.2ms      11.6±0.08ms     1.00  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_parameterized_subroutine(51)
       13.1±0.2ms       13.0±0.1ms     0.99  quantum_volume.QuantumVolumeBenchmark.time_ibmq_backend_transpile(2, 'translator')
          695±6ms          691±3ms     0.99  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_qv_14_x_14(3)
        176±0.7μs          175±1μs     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(8, 8)
          369±7ms          367±7ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_copy(1, 131072)
      1.34±0.02ms      1.33±0.01ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(5, 128)
       10.8±0.1ms       10.7±0.1ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(1, 2048)
          217±1ms        216±0.7ms     0.99  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm_backend_with_prop(1)
         498±10μs          494±2μs     0.99  circuit_construction.CircuitConstructionBench.time_circuit_copy(20, 128)
      5.94±0.05ms      5.89±0.04ms     0.99  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_single_schedule(31)
       76.8±0.4ms         76.2±1ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(8, 8192)
       90.2±0.7ms       89.5±0.2ms     0.99  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm(3)
      1.52±0.01ms      1.51±0.02ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(20, 128)
       1.24±0.01s       1.23±0.01s     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(14, 131072)
      1.33±0.01ms      1.31±0.01ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(14, 128)
         77.4±1ms       76.7±0.6ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(5, 8192)
          311±2ms          309±2ms     0.99  transpiler_levels.TranspilerLevelBenchmarks.time_schedule_qv_14_x_14(0)
          158±5ms          156±3ms     0.99  quantum_volume.QuantumVolumeBenchmark.time_ibmq_backend_transpile(8, 'translator')
         74.8±1ms         74.1±2ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(2, 8192)
       76.4±0.4ms         75.7±2ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(14, 8192)
        237±0.7ms        234±0.8ms     0.99  passes.MultipleBasisPassBenchmarks.time_basis_translator(5, 1024, ['rx', 'ry', 'rz', 'r', 'rxx', 'id'])
         954±10ms         944±10ms     0.99  quantum_volume.QuantumVolumeBenchmark.time_ibmq_backend_transpile(20, 'translator')
         541±10ms          535±7ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_copy(20, 131072)
          401±5ms          397±1ms     0.99  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_qv_14_x_14(2)
       37.6±0.2μs       37.2±0.4μs     0.99  circuit_construction.CircuitConstructionBench.time_circuit_copy(5, 8)
      6.47±0.03ms      6.40±0.03ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_copy(8, 2048)
      6.43±0.06ms      6.36±0.03ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_copy(5, 2048)
      6.60±0.04ms      6.52±0.03ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_copy(20, 2048)
       64.1±0.5μs         63.3±1μs     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(1, 8)
          295±2μs          291±1μs     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(14, 8)
         742±20μs          732±9μs     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(1, 128)
       18.7±0.4ms       18.5±0.3ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(14, 2048)
       1.48±0.02s       1.46±0.01s     0.99  transpiler_levels.TranspilerLevelBenchmarks.time_quantum_volume_transpile_50_x_20(0)
          176±2ms          173±1ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(1, 32768)
          863±5ms          851±2ms     0.99  transpiler_levels.TranspilerLevelBenchmarks.time_quantum_volume_transpile_50_x_20(1)
          419±1μs          413±2μs     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(20, 8)
          384±3μs          378±1μs     0.99  circuit_construction.CircuitConstructionBench.time_circuit_copy(2, 128)
          291±1μs          286±2μs     0.99  circuit_construction.CircuitConstructionBench.time_circuit_copy(1, 128)
       19.3±0.1ms      19.0±0.09ms     0.99  circuit_construction.CircuitConstructionBench.time_circuit_construction(8, 2048)
       2.91±0.04s       2.87±0.01s     0.98  transpiler_levels.TranspilerLevelBenchmarks.time_quantum_volume_transpile_50_x_20(3)
       26.5±0.2ms       26.1±0.2ms     0.98  circuit_construction.CircuitConstructionBench.time_circuit_copy(8, 8192)
        133±0.5μs          131±1μs     0.98  circuit_construction.CircuitConstructionBench.time_circuit_copy(20, 8)
         94.1±2ms         92.6±1ms     0.98  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm_backend_with_prop(3)
         774±20μs         761±20μs     0.98  pulse.schedule_construction.ParameterizedScheduleBench.time_assign_parameterized_subroutine(3)
          252±3ms        248±0.7ms     0.98  transpiler_levels.TranspilerLevelBenchmarks.time_schedule_qv_14_x_14(1)
          545±6ms          535±3ms     0.98  circuit_construction.CircuitConstructionBench.time_circuit_copy(14, 131072)
          456±8ms          448±2ms     0.98  passes.MultipleBasisPassBenchmarks.time_basis_translator(14, 1024, ['u', 'cx', 'id'])
       18.5±0.1ms       18.1±0.2ms     0.98  circuit_construction.CircuitConstructionBench.time_circuit_construction(2, 2048)
          207±4ms        202±0.8ms     0.98  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm_backend_with_prop(2)
          120±2ms          117±2ms     0.98  circuit_construction.CircuitConstructionBench.time_circuit_copy(2, 32768)
          269±2ms          263±3ms     0.98  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_qv_14_x_14(0)
       19.3±0.2ms       18.8±0.1ms     0.98  circuit_construction.CircuitConstructionBench.time_circuit_construction(5, 2048)
         549±10ms          535±5ms     0.97  circuit_construction.CircuitConstructionBench.time_circuit_copy(8, 131072)
          131±3ms          127±1ms     0.97  circuit_construction.CircuitConstructionBench.time_circuit_copy(5, 32768)
          131±2ms          127±1ms     0.97  circuit_construction.CircuitConstructionBench.time_circuit_copy(8, 32768)
       26.8±0.4ms       26.0±0.2ms     0.97  circuit_construction.CircuitConstructionBench.time_circuit_copy(14, 8192)
         54.0±2ms       52.4±0.4ms     0.97  quantum_volume.QuantumVolumeBenchmark.time_ibmq_backend_transpile(5, 'translator')
      1.36±0.01ms      1.32±0.01ms     0.97  circuit_construction.CircuitConstructionBench.time_circuit_construction(8, 128)
         27.6±2ms       26.7±0.3ms     0.97  circuit_construction.CircuitConstructionBench.time_circuit_copy(20, 8192)
          209±3ms          202±3ms     0.97  transpiler_levels.TranspilerLevelBenchmarks.time_transpile_from_large_qasm(2)
          548±7ms          529±4ms     0.97  circuit_construction.CircuitConstructionBench.time_circuit_copy(5, 131072)
         525±20ms          502±3ms     0.96  circuit_construction.CircuitConstructionBench.time_circuit_copy(2, 131072)

BENCHMARKS NOT SIGNIFICANTLY CHANGED.

Here are some updated benchmarks for how these changes affect memory pressure and runtime.
2Local 127Q
The graphs show a sweep from depth=0 to depth=2000. Peak memory use for this TwoLocal circuit with depth=2000 is reduced from ~665 MiB to ~552 MiB, but runtime is increased from ~78 s to ~114 s.
The increased runtime comes from QuantumCircuit.compose (used heavily by the NLocal class, at least compared to class QuantumVolume), which is now a bit slower since it (as before) does full iteration over CircuitData and ultimately calls CircuitData.append for every instruction. This just takes longer, since we need to unpack and repack the instructions via the interner.
In the future, we should consider porting QuantumCircuit.compose to Rust as well to shorten this loop, or better yet, rewrite portions of NLocal to use compose less extensively.
qc = TwoLocal(
    127,
    flatten=True,
    rotation_blocks=[SXGate(), "rz", SXGate()],
    entanglement_blocks=ECRGate(),
    entanglement='pairwise',
    reps=int(sys.argv[1])
)
qc._build()

Phony 2Local (HGate) 127Q
Same sweep as above, but using parameter-less gates. Notice that the peak memory use in both main and this branch are much lower, since singleton gates are in play. At depth=2000, we go from ~187 MiB to ~86 MiB, but runtime increases from ~52 s to ~89 s.
The increased runtime is explained also by the reduced speed of QuantumCircuit.compose.
qc = TwoLocal(
    127, flatten=True,
    rotation_blocks=[HGate(), HGate(), HGate()],
    entanglement_blocks=ECRGate(),
    entanglement='pairwise',
    reps=int(sys.argv[1])
)
qc._build()

QuantumVolume 127Q
The graphs show a sweep from depth=0 to depth=10_000. Peak memory use for this QuantumVolume circuit with depth=10_000 is reduced from ~998 MiB to ~935 MiB, and runtime is increased just slightly from ~159 s to ~163 s.
Unlike NLocal, the QuantumVolume implementation does not use QuantumCircuit.compose extensively, so the runtime doesn't take much of a hit here.
qv = QuantumVolume(127, int(sys.argv[1]), seed=1337)

Since you just posted those graphs while I was writing the review: the memory savings are a great start!  I think the runtime cost in QuantumCircuit.compose is too high, though, but there should be fairly easy fixes to it: a CircuitData::copy method that's exposed to Python space should be able to cut a whole bunch of time out, because it should be able to iterate through all its interned instructions and just increment the refcounts on the indices without needing to rehash/recompute everything.
That said, I'd seriously consider just dropping the refcounting for now unless we've got provable known use-cases where not having causes huge spikes in memory usage.  It feels to me like that shouldn't happen, because QuantumCircuit is additive-only, and since we intern only integer references, there's going to be far more re-use between circuits than there might otherwise be.

Currently do a bit of cleanup to the suggestions I've applied, so I'll ping reviewers once this is ready for another look.
I've also still got to finish investigating performance regressions.

Pull Request Test Coverage Report for Build 6739198398
Warning: This coverage report may be inaccurate.
We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

579 of 661 (87.59%)  changed or added relevant lines in 14 files are covered.
80 unchanged lines in 9 files lost coverage.
Overall coverage increased (+0.007%) to 86.902%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/accelerate/src/quantum_circuit/mod.rs
4
5
80.0%

qiskit/circuit/quantumcircuit.py
42
43
97.67%

crates/accelerate/src/quantum_circuit/intern_context.rs
24
27
88.89%

qiskit/circuit/instructionset.py
19
26
73.08%

qiskit/circuit/quantumcircuitdata.py
7
19
36.84%

crates/accelerate/src/quantum_circuit/circuit_instruction.rs
143
166
86.14%

crates/accelerate/src/quantum_circuit/circuit_data.rs
306
341
89.74%

Files with Coverage Reduction
New Missed Lines
%

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

qiskit/passmanager/passmanager.py
1
91.49%

qiskit/extensions/quantum_initializer/squ.py
2
84.15%

qiskit/passmanager/base_tasks.py
2
95.89%

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

qiskit/primitives/utils.py
5
89.02%

qiskit/transpiler/basepasses.py
8
91.58%

qiskit/passmanager/flow_controllers.py
11
66.12%

qiskit/visualization/dag_visualization.py
46
10.48%

Totals

Change from base Build 6723434770:
0.007%

Covered Lines:
74531

Relevant Lines:
85764

💛  - Coveralls

@jakelishman:

My real blocker comment is about the current problems with re-use of InternContext. I think we really need to work out what the problem is there, because re-use of the InternContext object is the sole reason to even have it reachable from Python space, and having it accessible there when it's somehow not thread-safe is to me far too much risk to expose.

Agreed. As such, InternContext is no longer exposed to Python. We can still share it between CircuitData copies under the hood, but we'll need to protect it with a lock of some sort since it'll be shared mutable state. I've opted to defer this to a separate PR if we feel the memory savings would be worth it.

I'd seriously consider just dropping the refcounting for now unless we've got provable known use-cases where not having causes huge spikes in memory usage.

Dropped. My original thinking was that it'd be important if we decided to share a single InternContext between all circuits and threads, which is something we've since decided against.

I think the runtime cost in QuantumCircuit.compose is too high.

Since generating the original graphs, I've pushed a few commits that tighten this up. I'll post updated graphs in the next few days.
There's still a lot of room for optimization on the table that I've been able to prove out in a separate branch. I need to rebase that work on this PR now, but will put out another PR for performance in the next few days. I'd considered including it for this PR, but the diff here is already too big. With those changes, QuantumCircuit.compose is actually faster than it is in main :D.

I'm not pressing "merge" yet because I'll give Matt another chance to look first, since there have been significant changes since his review.

authors: coveralls jakelishman kevinhartman

repo: Qiskit/qiskit


text:
Oxidize TwoQubitDecomposeUpToDiagonal

Summary
This commit ports the TwoQubitDecomposeUpToDiagonal class from Python to rust. This internal private class is used internally by the quantum shannon decomposition code, and while not performance critical was simple to port. One difference is while the original Python implementation was a class, it acted more like a function in practice. So the new rust version is exposed as a function.
Details and comments
TODO:

[x] Generate circuit rust side after #12459 merges

Pull Request Test Coverage Report for Build 9496622203
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

213 of 224 (95.09%)  changed or added relevant lines in 2 files are covered.
18 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.01%) to 89.593%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/accelerate/src/two_qubit_decompose.rs
207
218
94.95%

Files with Coverage Reduction
New Missed Lines
%

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

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

Totals

Change from base Build 9483656494:
-0.01%

Covered Lines:
62661

Relevant Lines:
69940

💛  - Coveralls

Pull Request Test Coverage Report for Build 9512074968
Details

228 of 239 (95.4%)  changed or added relevant lines in 2 files are covered.
9 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.04%) to 89.749%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/accelerate/src/two_qubit_decompose.rs
224
235
95.32%

Files with Coverage Reduction
New Missed Lines
%

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

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

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

Totals

Change from base Build 9503795487:
0.04%

Covered Lines:
63527

Relevant Lines:
70783

💛  - Coveralls

Pull Request Test Coverage Report for Build 9679860893
Details

228 of 239 (95.4%)  changed or added relevant lines in 2 files are covered.
6 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.02%) to 89.782%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/accelerate/src/two_qubit_decompose.rs
224
235
95.32%

Files with Coverage Reduction
New Missed Lines
%

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

Totals

Change from base Build 9676629284:
0.02%

Covered Lines:
63914

Relevant Lines:
71188

💛  - Coveralls

Pull Request Test Coverage Report for Build 9681374865
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

228 of 239 (95.4%)  changed or added relevant lines in 2 files are covered.
6 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.004%) to 89.764%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/accelerate/src/two_qubit_decompose.rs
224
235
95.32%

Files with Coverage Reduction
New Missed Lines
%

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

Totals

Change from base Build 9676629284:
0.004%

Covered Lines:
63901

Relevant Lines:
71188

💛  - Coveralls

Pull Request Test Coverage Report for Build 10075902733
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

225 of 236 (95.34%)  changed or added relevant lines in 2 files are covered.
136 unchanged lines in 9 files lost coverage.
Overall coverage decreased (-0.004%) to 89.927%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/accelerate/src/two_qubit_decompose.rs
221
232
95.26%

Files with Coverage Reduction
New Missed Lines
%

qiskit/transpiler/passes/layout/sabre_pre_layout.py
1
98.88%

qiskit/transpiler/passes/routing/commuting_2q_gate_routing/commuting_2q_gate_router.py
1
99.12%

qiskit/transpiler/passes/scheduling/alap.py
2
96.72%

qiskit/transpiler/passes/scheduling/asap.py
2
96.92%

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

qiskit/transpiler/passes/routing/layout_transformation.py
4
78.72%

qiskit/transpiler/instruction_durations.py
6
90.98%

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

qiskit/circuit/quantumcircuit.py
89
93.97%

Totals

Change from base Build 10067705422:
-0.004%

Covered Lines:
65977

Relevant Lines:
73367

💛  - Coveralls

authors: coveralls mtreinish


text:
Add memoization to StagedPassmanager

Summary
Simplifies code and improves readability by introducing memoization for expanded_stages in StagedPassmanager  through the cached_property decorator in functools. @mtreinish @jakelishman
Details and comments

Removes need to call parent class __setattr__.
Removes pylint ignores.
Removes need to set self._expanded_stages attribute.
Maintains efficiency and functionality thanks to self.expanded_stages immutability.

Pull Request Test Coverage Report for Build 2589632966

11 of 22 (50.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.01%) to 83.946%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/transpiler/passmanager.py
11
22
50.0%

Totals

Change from base Build 2585369189:
-0.01%

Covered Lines:
55784

Relevant Lines:
66452

💛  - Coveralls

This has merge conflicts due to the rewriting of the pass-manager structures in #10124 and #10127.  Given my above comment, I'm not super clear that the additional complexity added by this PR is worthwhile, but if this is something you feel strongly should be included in the StagedPassManager, feel free to re-open this PR / open a new one targetting the new structure (as appropriate).

authors: coveralls jakelishman pedrorrivero


text:
Make method example header bold to match class examples

fixes #202
I haven't been able to test this fix properly yet because our local docs build doesn't include any pages that uses API class or methods.

This was to fix #202, which we can't reproduce anymore.

authors: Eric-Arellano javabster


text:
[bug] qhub destroy failing on gcp

Running qhub destroy on GCP didn't work. Sometimes it looks like some timeouts need to be extended (could be worth looking into), but in this case, it spends five minutes trying to delete 'module.kubernetes-initialization.kubernetes_namespace.main' after already deleting the node pools.
That doesn't seem right, maybe a dependency tree needs to be set up in terraform somehow.
Logs here:
gcp_destroy_logs.txt

Also I've seen this - maybe because service account is deleted, other things can't be destroyed:
...
[terraform]: module.kubernetes.google_service_account.main: Destruction complete after 0s
[terraform]:
[terraform]: Error: rpc error: code = Unknown desc = Unauthorized
[terraform]:
[terraform]:
[terraform]:
[terraform]: Error: Unauthorized
[terraform]:
[terraform]:
[terraform]:
[terraform]: Error: Unauthorized
[terraform]:
[terraform]:
[terraform]:
[terraform]: Error: rpc error: code = Unknown desc = Unauthorized
[terraform]:
[terraform]:
[terraform]:
[terraform]: Error: Kubernetes cluster unreachable
[terraform]:

Maybe fixed by #621

repo: Quansight/qhub


text:
Update python to 2.0.7

Description

Update python to 2.0.7

See https://github.com/QuantConnect/pythonnet/pull/58
Related Issue

Closes https://github.com/QuantConnect/Lean/issues/5883
Motivation and Context

Bug fix and performance
Requires Documentation Change

N/A
How Has This Been Tested?

Unit and regression tests. Algorithm reproducing reported issue
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] Refactor (non-breaking change which improves implementation)
[x] Performance (non-breaking change which improves performance. Please add associated performance test and results)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Non-functional change (xml comments/documentation/etc)

Checklist:

[x] My code follows the code style of this project.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

Using algorithm shared at https://www.quantconnect.com/forum/discussion/9597/the-in-amp-out-strategy-continued-from-quantopian/p4/comment-36557
MASTER
309.04 seconds at 47k data points per second. Processing total of 14,593,222 data points.
309.79 seconds at 47k data points per second. Processing total of 14,593,486 data points.
PR
184.28 seconds at 79k data points per second. Processing total of 14,593,288 data points.
185.41 seconds at 79k data points per second. Processing total of 14,593,376 data points.

repo: QuantConnect/Lean


text:
initial implementation of conda history parsing

@marimeireles I had to rebase the PR because we pushed some of the files from the other PR to master already.
What's missing in this PR are functions to modify the history.
The history records all actions that conda / mamba did on a specific prefix such as installing or removing a package.
One needs to distinguish packages that are installed on user request (those are the "specs"), and just installed packages.
What we need now is to have a function where we can pass in new specs (packages that were asked to be installed, removed or neutered), and where we can give a list of newly installed and newly deleted packages and then write them out to the History file in the same format as conda does:
==> 2020-04-24 15:06:47 <==
# cmd: /home/wolfv/miniconda3/bin/mamba install pytorch -c defaults
# conda version: 4.8.3
+conda-forge/linux-64::ninja-1.10.0-hc9558a2_0
+defaults/linux-64::_pytorch_select-0.2-gpu_0
+defaults/linux-64::blas-1.0-mkl
+defaults/linux-64::cudatoolkit-10.1.243-h6bb024c_0
+defaults/linux-64::cudnn-7.6.5-cuda10.1_0
+defaults/linux-64::intel-openmp-2020.0-166
+defaults/linux-64::mkl-2020.0-166
+defaults/linux-64::mkl-service-2.3.0-py37he904b0f_0
+defaults/linux-64::pytorch-1.4.0-cuda101py37h02f0884_0
# update specs: ['pytorch']

The interface can probably look something like:
History
{
...

add_entry(const std::vector<std::string>& update_specs, const std::vector<std::string>& remove_specs, ..., )
{
}

}

Ah the cmake of the experiment has to add two files (if you are using explicit C++ files now):
	${CMAKE_SOURCE_DIR}/../src/history.cpp
	${CMAKE_SOURCE_DIR}/../src/match_spec.cpp
	${CMAKE_SOURCE_DIR}/../src/url.cpp

@marimeireles I just merged the branch so you can also work from master on the missing bits :)

repo: QuantStack/mamba


text:
fix const reference in xcontainer for const container

this fixes #631

This looks good to me. Good catch.

authors: SylvainCorlay wolfv

repo: QuantStack/xtensor


text:
Naming of Array.spox_var() and ndonnx.from_spox_var

We have had discussions recently about the naming of these functions. I believe there are two parts to consider here: the prefix and the suffix part.
Concerning the prefix, it might be valuable to harmonize the naming with the common unwrap prefix used in spox (e.g., Var.unwrap_tensor), which signals the fallibility nicely, IMHO. Concerning the suffix we may consider using only spox or var in the naming. Thus, I see the following options for the unwrap part:

unwrap_var
unwrap_spox
unwrap_spox_var
and one of the following constructor functions:
from_var
from_spox
from_spox_var

I'd be in favor of unwrap_spox_var and from_spox_var. Any thoughts, @adityagoel4512 @neNasko1

The falliability of to_spox_var is documented in the docstring although I can see why you say it might be clearer in unwrap_spox_var. If the main benefit is to make the name line up with Spox then I don't think that is a good enough reason for a breaking change. The ndonnx-Spox interoperability is used in a lot of different places.

We should take advantage of not being 1.x and do this. Let's not give ourselves a strong deadline to remove spox_var but unwrap_spox_var is good to me 👍.

repo: Quantco/ndonnx


text:
(new) Chain annotations and ChainManager control for them

Chain annotation control should move into the ChainManager since any build could potentially make use of them. We should be careful how we implement this because use cases are likely to expand over time.
We need to support multiple categories of annotations (the dims model allows for 'header title', 'center', 'left side', 'right side', 'footer title', 'center', 'left side' and 'right side') and multiple annotations per category (not just a single string). Multiple annotations per category would allow for setting up multiple rows of annotations for a single category in the Excel tables. A single annotation category could be given as a single string but that should be converted to a single-item list for consistency.
Quantipy needs a default set of annotation categories (keys), such as:
{
    "header-title": [...],
    "header-left": [...],
    "header-center": [...],
    "header-right": [...],
    "footer-title": [...],
    "footer-left": [...],
    "footer-center": [...],
    "footer-right": [...]
}

We should add a ChainAnnotation class inheriting from defaultdict to make using this simpler, otherwise the same code for working with it will end up being re-written for every build. Potentially, the class should only accept the expected annotation keys.
# key accessors
>>> chain.annotations['header-title']
[...]

>>> chain.annotations['footer-right']
[...]

# dotted accessors
>>> chain.annotations.header.title
[...]

>>> chain.annotations.footer.right
[...]

# list non-empty annotations (for easy iteration via key-accessors)
>>> chain.annotations.populated
["header-title", "footer-right"]

# easy iteration
>>> for key, annotation in chain.annotations.iteritems():
...     print key, annotation
'header-title' [...]
'footer-right' [...]

# convenient repr (showing only populated annotations
>>> print chain.annotations
Headers
- title: [...]
Footers
- right: [...]

The ChainManager will need to make it easy to get/set the annotations for its chains.
Firstly this should be supported with the addition of .get_chains(..., annotations). Where there is only 1 x-key this annotations could be an instance of ChainAnnotation or a dict (as above) that can easily instantiate a ChainAnnotation. Where there is more than 1 x-key it must be a dict of the same keyed to those x-keys.
Getting/setting chain annotations for the chains in a populated ChainManager could also be done by referencing the x-key of the chains, but there's no guarantee currently that each x-key will in a ChainManager will be unique (since .get_chain() could be used multiple times). The chances that this would be the case are probably rare though so we could accept a failure in this case and direct the user to find the chain they're actually after manually and add the annotation to that chain directly.

@AlasdairE

I have added the basic Class for this (dict like, annotation types, getitem, setitem overloading to restricted annotation keys, set_annotations(), etc.)
@jamesrkg
Let's chat about how to connect with the ChainManager class in the contect of folders and general naming conventions.

Done and merged.

authors: alextanski jamesrkg

repo: Quantipy/quantipy


text:
DRAFT: chores and trivial cleanups

the chore branch collects trivial changes that may not worth dedicated PRs into main. Feel free to open PRs to chore, or just drop me some patches.

next round of cleanups, notably some URING related (dead)code are removed. Discussions here: https://github.com/QuarkContainer/Quark/pull/1309

repo: QuarkContainer/Quark


text:
Units freeze mid battle - unplayable afterwards

I think i discovered a bug, possibly related to GW-AI-Overhaul for Planetary Annihilation Titans.
What happens:
When I play galactic war, during a battle, units completely freeze. I can select them with my mouse, i can spin the planet, i can zoom in etc., but all units and explosions are static. Note that this happens during the first battle in galactic war with GW-AI-Overhaul active, not on vanilla. This problem has been noted by multiple players in steam troubleshooting discussions.
Mods installed during playthrough:
Galactic War Overhaul, PA Chat, WPMarshall's Map Pack, More Pew Pew, Milkyway Skybox, System Sharing for Titans & Classic
*My PC setup is more than powerful enough, nevertheless I play on medium details as to not lag on gigantic battles full of orbital units etc.
What will I try next:
I will try to disable all mods, especially more pew pew and test it again and see how the works.
Picture with performance analysis on the upper right corner (also as you can see, the game is not PAUSED, nor already over, this is a battle in session):

To be reported without other mods present using bug reporting template.

repo: Quitch/GW-AI-Overhaul


text:
feat: Add report format reminder

Closes #80

Thanks for the PR <3

authors: Bobbyperson GeckoEidechse


text:
Template generator inverses run on client and server

Perhaps a gitignore should be added to templates.

fixed by aab2bff


text:
Add support for Kafka

@krasserm I've started rudimentary work on this and think a separate eventuate-kafka sub-module and its KafkaEventLog etc are preferable - for people not needing Kafka and it's dependencies. While Cassandra is integrated in the eventuate core module, I don't think it wise to put my PR code in there additionally. Many of us using C* also use Kafka but it would cause bloat. Kafka is used in larger systems like I am on but smaller seem to write directly to C*.

For timing/roadmap purposes, my hope is to have this PR ready in the next month, at least for review cycles, and leverage it at my kafka summit talk in April :)

@helena :+1: thanks a lot for working on it, really looking forward to see the PR.
Regarding an eventuate-kafka sub-module, we anyway plan to make Eventuate a multi-module project (see #169). So I think it's ok to initially put the Kafka integration into a separate package on the same level as cassandra and leveldb. It will anyway become a separate module when #169 is due (planned for the next 0.6 release). Also take a look at failure handling which has a strong impact on storage plugin implementation.

@krasserm Sounds good :)

@krasserm I need to put this off for 2 or so weeks. If you get to it first, great. Otherwise I'll be back at it soon.

@helena thanks for letting me know. I have other priorities at the moment, so chances are very low I'll do something on this ticket :smiley:. BTW in 2 weeks #169 should be ready I think.

Sweet! K finally getting back to this.

@helena I'm about to revise the Eventuate documentation and also added an FAQ entry How does Apache Kafka relate to Eventuate? in https://github.com/RBMHTechnology/eventuate/commit/62222f8c54798fd3d934ddd9f0224e3448570334 as I've frequently heard that question. Which of the two integration options do you plan to work on? Or can you imagine another one?

Just found the new Kafka proposal for idempotent producers and transactional messaging. The idempotent producer is exactly what we need for using Kafka as event sourcing storage backend.

That's great news!

On 1 Dec 2016, at 07:46, Martin Krasser notifications@github.com wrote:
Just found the new Kafka proposal for idempotent producers and transactional messaging. The idempotent producer is exactly what we need for using Kafka as event sourcing storage backend.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

authors: helena krasserm odd

repo: RBMHTechnology/eventuate


text:
Is that possible to decode like this 👇

Because I am trying to making something like this..is that possible with this lib sir

For example im upload this project  .

For example im upload this project  .

Yes sir you got it right...this is what I need..Thanks for your reply sir ❤

Provide more description for your question

Arsc Sample.zip
Plz sir see the above Decompiled arsc sample...can we do this with the help of this library...☺..And after edit we can compile the whole folder path to a arsc binary file.. Sir

With ARSCLib you can compile/decompile resources to JSON or XML, if you are java/android developer you can edit resources directly without the need of decompiling

And from your example I experienced that how to patch a arsc file using your library...
Your example somthing like below
public static void exampleResourceTable() throws IOException{
File inFile=new File("resources.arsc");
    // *** Loading resource table ***
    TableBlock tableBlock=TableBlock.load(inFile);

    Collection<PackageBlock> packageBlockList=tableBlock.listPackages();
    System.out.println("Packages count = "+packageBlockList.size());
    for(PackageBlock packageBlock:packageBlockList){
    System.out.println("Package id = "+packageBlock.getId()
    +", name = "+packageBlock.getName());
    }

    // *** It's a patching method sir ☺
    // Change package name
    for(PackageBlock packageBlock:packageBlockList){
    String name = packageBlock.getName();
    String newName = name + ".new-name";
    packageBlock.setName(newName);
    }

    // Refresh to re-calculate offsets
    tableBlock.refresh();
    // Save
    File outFile=new File("resources_out.arsc");
    tableBlock.writeBytes(outFile);

But I want whole arsc resources are Decompiled and saved in a directory..after editing then it should come to normal mode like resources.arsc (binary format)...
    System.out.println("Saved: "+outFile);
    }

Did you checked https://github.com/REAndroid/APKEditor ?

Did you checked https://github.com/REAndroid/APKEditor ?

Yes sir I checked it ...but I unable to understand the usage.,. If possible please vividly explain me sir ... thank you for giving me your valuable time 🙏

Did you checked https://github.com/REAndroid/APKEditor ?

Sir tell me the usage that how can I convert resources.arsc to XML format and then build back..plz sir tell me the usage of this 🙏

@developer-krushna see this classes
https://github.com/REAndroid/APKEditor/blob/master/src/main/java/com/reandroid/apkeditor/decompile/Decompiler.java
https://github.com/REAndroid/APKEditor/blob/master/src/main/java/com/reandroid/apkeditor/compile/Builder.java

authors: MrIkso REAndroid developer-krushna

repo: REAndroid/ARSCLib


text:
🛑 RED7 Staff - Passwords is down

In 520a513, RED7 Staff - Passwords (https://bitwarden.red7.ml) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RED7 Staff - Passwords is back up in c3ed12c.


text:
CMake, clang warning stuff and consistency

clang was putting out warning about unused option -rdynamic for compilation. From what I gathered it is only actually needed when linking. Needs 3.13, though.
I looked at the compile warnings clang reported, and found the one instance were override should have been specified.
Also renamed the lonely *.h header to *.hpp for consistency.

Ohh the ci is not set up with cmake 3.13 lol.

Seems like the Windows build is fine. Kitware has an official way of installing the latest CMake version on Ubuntu 16.04. You could just shove that into the yaml file for linux: https://apt.kitware.com

I was not quite sure how that would work with the cmake installation already present on the image.
Lets see.

you can sudo apt-get purge cmake before. Although updating should also work just fine.

Hmm, it looks like it's installing cmake 3.15 properly but then still uses the old installation?

Seems like CMake is installed manually. So I dont think purging would work.
Maybe I am just going to remove it manually.

Thanks for your work, I appreciate it!

authors: KirmesBude ataulien

repo: REGoth-project/REGoth-bs


text:
🛑 Cleanse Drops Kidney is down

In 19e1b21, Cleanse Drops Kidney (http://cleansedropskidney.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Cleanse Drops Kidney is back up in a617162 after 12 minutes.

repo: RJVCA/uptime


text:
🛑 Activated Male is down

In 31005c9, Activated Male (http://activatedmale.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Activated Male is back up in 416c86c after 11 minutes.


text:
🛑 Activated Male is down

In b4d81e3, Activated Male (http://activatedmale.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Activated Male is back up in b955fa4 after 10 minutes.


text:
🛑 Sensor Tracker login is down

In 2a0dc05, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in 58d2c5f after .

repo: RKTowse/upptime


text:
🛑 Sensor Tracker login is down

In 27a49e8, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in 70e543f after 1 minute.


text:
🛑 Sensor Tracker login is down

In 9c02071, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in cb5e8e0 after 1 minute.


text:
🛑 Sensor Tracker login is down

In 87b77dd, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in df51136 after .


text:
🛑 Sensor Tracker login is down

In 29e7c34, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in 9dafa4d after 1 minute.


text:
🛑 Sensor Tracker login is down

In 696b8f7, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in e2c970b after .


text:
🛑 Sensor Tracker login is down

In c1a4202, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in 5614441 after .


text:
🛑 Sensor Tracker login is down

In 2e4f6ba, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 502
Response time: 110 ms

Resolved: Sensor tracker login is back up in 0d5d255.