`extern port` / `extern frame` in `cal` blocks fail to parse, blocking nearly every spec OpenPulse example
Maintainer thường phản hồi trong vòng 1 ngày
@Riiocodee đang làm issue này rồi.
Từ ngày 19/10/2026.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- python
- Lĩnh vực
- compilers, quantum-computing
Hướng nghiên cứu
Start in src/pyqasm/pulse/, where cal bodies go to openpulse.parser.parse_openpulse, and reproduce the extern port d0; failure with the openpulse parse call from the issue. The workaround in src/pyqasm/pulse/frame.py and the openpulse>=1.0.1 pin in the pulse extra of pyproject.toml need a maintainer decision first. Done means the surfaced error names the upstream limitation and the spec examples are added as xfail fixtures.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Limitation
The OpenPulse chapter declares ports and frames provided by
the backend with extern:
extern port d0;
extern frame d0f;
This is the standard idiom — the Ports and
Frames sections use it, and so does essentially every
worked example in the chapter, along with
Calibrations in practice.
Every one of them fails in pyqasm.
Example QASM failure
OPENQASM 3.0;
defcalgrammar "openpulse";
cal {
extern port d0;
frame d0f = newframe(d0, 5.0e9, 0.0);
}
ValidationError: Failed to parse OpenPulse string: Unexpected token 'port' at line 4, column 11.
OPENQASM 3.0;
defcalgrammar "openpulse";
cal { extern frame m0f; }
defcal measure $0 -> bit {
return capture_v2(m0f, 2048ns);
}
// ValidationError: Failed to parse OpenPulse string: Unexpected token 'frame' at line 3, column 8.
Without extern, the same declarations parse:
cal {
port d0; // OK
frame f = newframe(d0, 5.0e9, 0.0); // OK
}
Root cause — upstream
This is not a defect in pyqasm's own code. The openpulse 1.0.1 parser rejects it
directly:
>>> from openpulse import parse
>>> parse('OPENQASM 3.0;\ncal {\n extern port d0;\n}\n')
openpulse.parser.OpenPulseParsingError: Unexpected token 'port' at line 2, column 10.
>>> parse('OPENQASM 3.0;\ncal {\n extern frame d0f;\n}\n')
openpulse.parser.OpenPulseParsingError: Unexpected token 'frame' at line 2, column 10.
The externDeclaration production accepts only classical types as parameters, so the
port / frame keywords are unexpected there.
Filing it here because the user-visible effect is that pyqasm cannot analyse the spec's pulse
examples, and because the fix needs tracking and a version bound on our side.
Change Requested
- Open an issue on
openqasm/openqasmagainst the
openpulsePython package, with the reproducer above, and link it back here. - Once fixed upstream, raise the
openpulsefloor in thepulseextra inpyproject.toml
and add the spec examples as test fixtures. - Until then, improve the error surfaced to users.
"Failed to parse OpenPulse string: Unexpected token 'port'"gives no indication that this is a known upstream limitation
rather than a mistake in their program. - Decide whether to carry a temporary workaround — see below.
Implementation Details
- The pulse path is
src/pyqasm/pulse/;cal/defcalbodies are handed to
openpulse.parser.parse_openpulse, and the error above is re-raised from there. The
pulseextra pinsopenpulse>=1.0.1inpyproject.toml. - Possible interim workaround: strip a leading
externfromport/framedeclarations
before handing the body to the parser, then mark the resulting symbol as externally provided
inpyqasm's own frame/port table (src/pyqasm/pulse/frame.py).port d0;and
frame f = newframe(...);already parse, so the rewrite is narrow. It is a text-level
workaround and should be gated behind a clear comment and removed once upstream lands —
maintainer call on whether that trade is worth it. - Verify against the latest
openpulserelease before filing upstream; this was reproduced on
1.0.1. - Tests: add the spec's Ports, Frames and Calibrations-in-practice examples as fixtures, marked
xfailwith a reference to the upstream issue so they flip to passing automatically when the
dependency is bumped.
- Ngôn ngữ chính
- Python
- Star
- 29
- Fork
- 33
- Merge trung bình
- 2 ngày 4 giờ
- Pull request đã merge (30 ngày)
- 15
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của qBraid/pyqasm
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 63/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement error-handling program-validation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Move the QASM 2 printer and its branch pre-processing out of qasm2.pyCó thể đã có người làm @danielgaskins đã nhận 7 ngày trước. Đang mởenhancement qasm2
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 22/100
qBraid/pyqasm#447 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] dumps() emits extern calls without a semicolon, producing unparsable QASMCó thể đã có người làm @Jah-yee đã nhận 16 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 25/100
qBraid/pyqasm#438 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Parse failures raise ValidationError with an empty message; the ANTLR diagnostic is lostCó thể đã có người làm @tonycoder-hub đã nhận 9 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 22/100
qBraid/pyqasm#436 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của qBraid/pyqasm
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
-
[Bug]: Queen's own Ollama model loses num_ctx when a running session switches to itCó thể đã có người làm @anasamin26 đã nhận hôm nay. Đang mởbug enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
aden-hive/hive#7508 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
llm translation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
BerriAI/litellm#47884 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug 🐛
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
netalertx/NetAlertX#1856 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày