Fully port ALAPScheduleAnalysis to Rust #14664

phalakbh · 2025-06-24T20:38:05Z

Summary

This PR migrates the implementation of the ALAPScheduleAnalysis pass from Python to Rust, maintaining identical scheduling logic and user-facing behavior.

Details and comments

Fixes #12258

No changes have been made to the scheduling algorithm or its logic.

…module

qiskit-bot · 2025-06-24T20:38:11Z

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the following people are relevant to this code:

@Qiskit/terra-core

coveralls · 2025-06-24T21:39:42Z

Pull Request Test Coverage Report for Build 16786305064

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

142 of 147 (96.6%) changed or added relevant lines in 4 files are covered.
2345 unchanged lines in 99 files lost coverage.
Overall coverage decreased (-0.4%) to 87.659%

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/transpiler/src/passes/alap_schedule_analysis.rs	135	140	96.43%

Files with Coverage Reduction	New Missed Lines	%
crates/accelerate/src/circuit_library/multi_local.rs	1	99.39%
crates/accelerate/src/results/marginalization.rs	1	90.45%
crates/cext/src/circuit.rs	1	80.73%
crates/circuit/src/classical/expr/binary.rs	1	98.68%
crates/circuit/src/classical/expr/cast.rs	1	79.63%
crates/circuit/src/classical/expr/index.rs	1	98.15%
crates/circuit/src/classical/expr/stretch.rs	1	93.65%
crates/circuit/src/classical/expr/unary.rs	1	83.82%
crates/circuit/src/classical/expr/value.rs	1	97.87%
crates/circuit/src/classical/expr/var.rs	1	92.16%

Totals
Change from base Build 15859139979:	-0.4%
Covered Lines:	81910
Relevant Lines:	93442

💛 - Coveralls

raynelfss

This looks pretty good for a start, I have a couple comments.

raynelfss · 2025-06-25T13:10:10Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    clbit_write_latency: u64,
+    node_durations: &Bound<PyDict>,
+) -> PyResult<Py<PyDict>> {
+    if dag.qregs().len() != 1 || !dag.qregs().iter().any(|reg| reg.name() == "q") {


To avoid iterating over all the registers in the dag, you can use dag.qregs_data() to get an immutable reference to the inner RegisterData within the dag. This may also allow you to use RegisterData::contains_key which accepts a register name for querying.

raynelfss · 2025-06-25T13:39:49Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    let mut node_start_time: HashMap<NodeIndex, f64> = HashMap::new();
+    let mut idle_before: HashMap<Wire, f64> = HashMap::new();
+
+    for (i, _) in dag.qubits().objects().iter().enumerate() {
+        idle_before.insert(Wire::Qubit(Qubit::new(i)), 0.0);
+    }
+
+    for (i, _) in dag.clbits().objects().iter().enumerate() {
+        idle_before.insert(Wire::Clbit(Clbit::new(i)), 0.0);
+    }


For this you may not have to iterate over ObjectRegistry::objects(). Since the indices are always contiguous in cases like these, you may want to just do something of the sorts of:

for index in 0..dag.qubits().len() { idle_before.insert(Wire::Qubit(Qubit::new(i)), 0.0); }

raynelfss · 2025-06-25T13:44:47Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    for node_index in dag
+        .topological_op_nodes()?
+        .collect::<Vec<_>>()
+        .into_iter()
+        .rev()


Is there a reason you need to collect this iterator before reversing it?

The reason is that for ALAP Scheduling, nodes are scheduled in reverse topological ordering (unlike ASAP) and are packed from the end of the circuit. I will move the comment from lines 84-92 above this so that it becomes more readable.

raynelfss · 2025-06-25T15:13:58Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    py: Python,
+    dag: &DAGCircuit,
+    clbit_write_latency: u64,
+    node_durations: &Bound<PyDict>,


If node_durations is a dictionary of DAGNode and f64. Maybe we should try to find a way of displaying this with a Rust native struct, or maybe just bringing InstructionDurations to Rust might solve this.

raynelfss · 2025-06-25T15:51:06Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+
+        let op = match dag.dag().node_weight(node_index) {
+            Some(NodeType::Operation(op)) => op,
+            _ => continue,


More of a nitpick, but you could use panic!() here. Though it is a bit of a drastic measure considering that panic will stop the process and cannot be caught in Python, there's no reason why topological_op_nodes() should give you anything that isn't an instance DAGOpNode.

raynelfss · 2025-06-25T16:50:51Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+            OperationRef::Gate(_) => (true, false),
+            OperationRef::StandardGate(_) => (true, false),
+            _ => (false, op_name == "delay"),


Suggested change

OperationRef::Gate(_) => (true, false),

OperationRef::StandardGate(_) => (true, false),

_ => (false, op_name == "delay"),

OperationRef::Gate(_) => (true, false),

OperationRef::StandardGate(_) => (true, false),

OperationRef::StandardInstruction(StandardInstruction::Delay(_)) => (false, true),

_ => (false, op_name == "delay"),

You might want to add this condition for completion's sake.

raynelfss · 2025-06-25T16:52:50Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+        // Get operation type
+        let op_name = op.op.name();
+        let op_view = op.op.view();
+        let (is_gate, is_delay) = match op_view {


Nitpick: This could be simplified to be one boolean value instead of two.

raynelfss · 2025-06-25T17:14:36Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    let node_start_time_final: HashMap<NodeIndex, f64> = node_start_time
+        .into_iter()
+        .map(|(n, t1)| (n, circuit_duration - t1))
+        .collect();


You could avoid this step if you're going to convert to a PyDict anyway. But if that's the case you should probably consider having a Rust native version of this function that returns a HashMap, and then have the Python version perform the conversion to Python types.

raynelfss · 2025-06-25T17:24:54Z

test/benchmarks/passes.py

+class ALAPScheduleAnalysisPassBenchmarks:
+    params = ([5, 14, 20], [1024])
+
+    param_names = ["n_qubits", "depth"]
+    timeout = 300
+
+    def setup(self, n_qubits, depth):
+        seed = 42
+        self.circuit = random_circuit(
+            n_qubits, depth, measure=True, conditional=True, reset=True, seed=seed
+        )
+        self.dag = circuit_to_dag(self.circuit)
+        gate_names = {inst[0].name for inst in self.circuit.data}
+        self.durations = InstructionDurations([(name, None, 1000) for name in gate_names], dt=1e-7)
+
+    def time_alap_schedule_analysis(self, _, __):
+        ALAPScheduleAnalysis(durations=self.durations).run(self.dag)
+


I think there are tests that perform something similar to this, check tests/benchmarks/scheduling_passes.

Oh, I think I may have missed that. I have removed this class from the file.

This reverts commit e240bae.

…prove docstrings for clarity - The run method now constructs node_durations as a Python dict mapping node indices to durations, which is passed to Rust as a native HashMap<usize, f64>. - Enhanced docstrings for the ALAPScheduleAnalysis class and run method to clarify scheduling behavior

raynelfss

This is progressing quite well. I still think you could tweak it around to work a bit better, considering the rust side of things. Remember, we should be able to rust this pass without necessarily calling Python.

raynelfss · 2025-07-11T14:18:15Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    py: Python,
+    dag: &DAGCircuit,
+    clbit_write_latency: u64,
+    node_durations: HashMap<usize, f64>,


Hmmm... I'm not quite sure using this type should be the best way of going around this. It should be best to use the defined NodeIndex type. Though I get you won't be able to directly extract it from Python, but there should be a way around that too...

raynelfss · 2025-07-11T14:18:35Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+pub fn run_alap_schedule_analysis(
+    py: Python,
+    dag: &DAGCircuit,
+    clbit_write_latency: u64,
+    node_durations: HashMap<usize, f64>,
+) -> PyResult<Py<PyDict>> {


If we're trying to keep everything rust native, is there a way you could return a HashMap for this too? We want to be able to run this pass standalone (that meaning running the pass entirely from rust without it depending on Python for anything).

You might still be able to receive a PyDict of type { node_type: duration_type } while keeping a path open for rust users to use the respective rust native types. Which would allow you to remove the python types altogether for a rust side without changing anything from what you've done on the Python side.

raynelfss · 2025-07-11T14:24:21Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    // Note that ALAP pass is inversely scheduled, thus
+    // t0 is computed by subtracting t1 from the entire circuit duration.
+    let py_dict = PyDict::new(py);
+    for (node_idx, t1) in node_start_time {
+        let node = dag.get_node(py, node_idx)?;
+        let time = circuit_duration - t1;
+        if time.fract() == 0.0 {
+            py_dict.set_item(node, time as u64)?;
+        } else {
+            py_dict.set_item(node, time)?;
+        }
+    }


This step shouldn't be in a Rust native function. Though it is still necessary to achieve what you want. There should be a way of not making this conversion to a PyDict required.

raynelfss · 2025-07-11T14:28:54Z

qiskit/transpiler/passes/scheduling/scheduling/alap.py

+        node_durations = {
+            node._node_id: self._get_node_duration(node, dag) for node in dag.topological_op_nodes()
+        }


Hmm... I'm not quite sure you should you should be accessing node._node_id here, even though it is a python expose method. Perhaps you could keep the accessing the node_id in Rust instead of here. Afterall DAGNode is still a PyO3 struct and it stores an optional instance of NodeIndex, the rust native indexing type for DAG.

raynelfss · 2025-07-15T19:29:34Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    for node_index in dag
+        .topological_op_nodes()?
+        .collect::<Vec<_>>()
+        .into_iter()
+        .rev()


Why are we going back to the topological op_nodes of the dag here? I believe you already did this in Python and what we receive here is a dict of {DAGNode : duration }, if that's the case, why are you doing this iteration again? I think you might benefit from just using the data you obtained from Python.

…ap_schedule_analysis, remove the extra node iteration.

raynelfss

This is almost ready. However, there is still one big pain point that you had brought up before: Dealing with durations where the unit is either seconds or dt. I left a suggestion on how to better handle it in one of my comments.

raynelfss · 2025-07-17T16:37:22Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+            .extract::<DAGNode>()?
+            .node
+            .expect("Node index not found.");


Nitpick: For the extraction here, an extra step you could add is to use downcast to cast the node into a DAGOpNode and then extract the DAGNode just to make sure we are receiving DAGOpNodes.

It could look somewhat like:

let node_idx = py_node .downcast_into::<DAGOpNode>()? .extract::<DAGNode>()? .node .expect("Node index not found.");

raynelfss · 2025-07-17T16:49:26Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+        let op = match dag.dag().node_weight(node_index) {
+            Some(NodeType::Operation(op)) => op,
+            _ => panic!("topological_op_nodes() should only return instances of DagOpNode."),
+        };


I think that now you should be able to access the DAG via indexing to get the node's weight (NodeType). And you also have the unwrap_operation() to get the PackedInstruction.

Suggested change

let op = match dag.dag().node_weight(node_index) {

Some(NodeType::Operation(op)) => op,

_ => panic!("topological_op_nodes() should only return instances of DagOpNode."),

};

let op = dag[node_index].unwrap_operation();

raynelfss · 2025-07-17T19:01:36Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+        if t1.fract() == 0.0 {
+            py_dict.set_item(node, t1 as u64)?;
+        } else {
+            py_dict.set_item(node, t1)?;
+        }


Although this looks like a good way of handling things, it may not be the case. Since you'd want to preserve the integer cases (for dt), maybe you'd have to do something different. Perhaps finding a way of receiving either a float (seconds) or int (dt) from Python in Rust depending on whether the duration's unit. Since we only ever use either two for this pass and all durations will always be of the same type for each one circuit, you could create something that allows you to handle each unit. Perhaps with an enum.

phalakbh · 2025-07-18T18:03:39Z

Thank you, I have addressed the comments and created an enum TimeValue that takes care of type handling of duration values. Let me know if this needs further modifications.

raynelfss

A couple more comments about the new enumeration.

raynelfss · 2025-07-21T18:20:39Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    fn from_f64(value: f64, is_int_type: bool) -> TimeValue {
+        if is_int_type {
+            TimeValue::Int(value as u64)
+        } else {
+            TimeValue::Float(value)
+        }
+    }


You should implement this using the From<T> trait. With this you could automatically transform integers into TimeValue::Int and f64 is correctly cast into TimeValue::Float.

raynelfss · 2025-07-21T18:21:29Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    fn as_f64(&self) -> f64 {
+        match self {
+            TimeValue::Float(f) => *f,
+            TimeValue::Int(i) => *i as f64,
+        }
+    }


I don't believe this might be the right usage. You should maybe focus on handling any operation in a case to case basis, just to handle things more cleanly.

I comment on this mainly because casting from float back to int is a bit wonky.

…sis per node

raynelfss

I think you're getting closer but there are some things that need ironing out.

I believe that, for any duration provided, the unit will end up being the same based on what the BaseScheduler pass does. Based on whether the provided durations there are in terms of dt or not (s), the _get_node_duration() method will always provide units of the same type. This should influence your approach when handling the two different types here.

raynelfss · 2025-07-22T17:15:15Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+        } else if let Ok(val) = py_duration.extract::<f64>() {
+            val.into()
+        } else {
+            return Err(TranspilerError::new_err("Duration must be u64 or f64"));


Suggested change

return Err(TranspilerError::new_err("Duration must be u64 or f64"));

return Err(TranspilerError::new_err("Duration must be int or float"));

Nitpick: Since this error message is only exposed to Python, we can use int or float instead of the rust types.

raynelfss · 2025-07-22T17:16:21Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    let mut node_start_time: HashMap<NodeIndex, f64> = HashMap::new();
+    let mut idle_before: HashMap<Wire, f64> = HashMap::new();


What's the guarantee that these types are always float and they don't match the same unit as the duration?

raynelfss · 2025-07-22T17:18:52Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    let mut result: HashMap<NodeIndex, TimeValue> = HashMap::new();
+    for (node_idx, t1) in node_start_time {
+        let final_time = match node_durations.get(&node_idx) {
+            Some(TimeValue::Int(_)) => TimeValue::from((circuit_duration - t1).round() as u64),


I'm not sure we should be rounding things for the calculation. If we're dealing with TimeValue::Int from the beginning, shouldn't t1 and circuit_duration also be of TimeValue::Int too??

Done in 8cc9893! All variables and HashMaps now use the TimeValue enum, so the need of typecasting/ rounding values anywhere is eliminated.

… to use TimeValue throughout.

raynelfss

This looks much better as this approach reduces the lines of code needed to achieve the same result. I had a couple of comments and suggestions.

raynelfss · 2025-08-06T13:22:12Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+pub trait TimeOps: Copy + PartialOrd + Add<Output = Self> + Sub<Output = Self> {
+    fn zero() -> Self;
+    fn max<'a>(a: &'a Self, b: &'a Self) -> &'a Self;
+    fn from_u64(val: u64) -> Self;


Why is the from_u64 needed here?

I had included this function mainly for clbit_write_latency. Since it is always provided as u64 type, It would need to be converted to T to make the data types consistent for the addition/subtraction operations, but I realized the type conversion for it could be done at the function calling stage itself. So I have removed the from_u64 method completely.

raynelfss · 2025-08-06T13:31:02Z

crates/transpiler/src/passes/alap_schedule_analysis.rs

+    let mut op_durations_int: Option<HashMap<NodeIndex, u64>> = None;
+    let mut op_durations_float: Option<HashMap<NodeIndex, f64>> = None;


Is there a reason why you're having these co-exist? I believe you can deal with each case individually within their respective if clauses, and do all of the python processing within those as well.

Done in the latest commit!

…_durations only once.

…tring

raynelfss

Thanks for the quick update

* Implement ALAP scheduling analysis in Rust and integrate with Python module * Fix lint issues * Add benchmark for ALAPScheduleAnalysis to passes.py * Add copyright and licensing information to alap_schedule_analysis.rs * Refactor ALAP schedule analysis based on suggestions * Remove the benchmark added to passes.py * Fix lint issues * Refactor comments in ALAP schedule analysis * Fix more lint issues * Simplify node duration handling and update function signature * Revert "Simplify node duration handling and update function signature" This reverts commit e240bae. * Update run function to pass node_durations as native Rust HashMap; improve docstrings for clarity - The run method now constructs node_durations as a Python dict mapping node indices to durations, which is passed to Rust as a native HashMap<usize, f64>. - Enhanced docstrings for the ALAPScheduleAnalysis class and run method to clarify scheduling behavior * Make documentation consistent * Fix lint * Split the pass into Rust-native function and Python-facing wrapper * Fix lint * Fix failing tests by move the type conversion logic back to py_run_alap_schedule_analysis, remove the extra node iteration. * Add enum for type handling of duration values * Rename enum to TimeValue * Implement From trait, ensure conversion to integer on case to case basis per node * Modify TimeValue to support arithmetic and max ops; update scheduling to use TimeValue throughout. * Replace enum with TimeOps trait for improved type flexibility * Remove from_u64 method from TimeOps trait; Refactor code to create op_durations only once. * Add back documentation example; Update node_duration argument in docstring

phalakbh added 2 commits June 25, 2025 01:31

Implement ALAP scheduling analysis in Rust and integrate with Python …

0f1e04f

…module

Merge branch 'Qiskit:main' into alap-scheduler-analysis

3d84bf2

phalakbh requested a review from a team as a code owner June 24, 2025 20:38

qiskit-bot added the Community PR PRs from contributors that are not 'members' of the Qiskit repo label Jun 24, 2025

github-project-automation bot added this to Contributor Monitoring Jun 24, 2025

Fix lint issues

5cfeac6

phalakbh added 2 commits June 25, 2025 11:56

Add benchmark for ALAPScheduleAnalysis to passes.py

7124060

Add copyright and licensing information to alap_schedule_analysis.rs

517e9fe

raynelfss self-assigned this Jun 25, 2025

raynelfss reviewed Jun 25, 2025

View reviewed changes

phalakbh added 5 commits June 26, 2025 13:07

Refactor ALAP schedule analysis based on suggestions

c55b796

Remove the benchmark added to passes.py

22b4b39

Fix lint issues

cd999fe

Refactor comments in ALAP schedule analysis

fde5cea

Fix more lint issues

6e4d5c4

Simplify node duration handling and update function signature

e240bae

raynelfss added this to the 2.2.0 milestone Jul 7, 2025

phalakbh added 2 commits July 11, 2025 16:01

Revert "Simplify node duration handling and update function signature"

a2ed118

This reverts commit e240bae.

phalakbh requested a review from raynelfss July 11, 2025 11:25

phalakbh added 2 commits July 11, 2025 17:06

Make documentation consistent

465a1af

Fix lint

20da5f5

raynelfss reviewed Jul 11, 2025

View reviewed changes

phalakbh added 2 commits July 15, 2025 01:39

Split the pass into Rust-native function and Python-facing wrapper

cf18b4f

Fix lint

cb597b5

raynelfss reviewed Jul 15, 2025

View reviewed changes

Fix failing tests by move the type conversion logic back to py_run_al…

cabe1ad

…ap_schedule_analysis, remove the extra node iteration.

raynelfss reviewed Jul 17, 2025

View reviewed changes

phalakbh added 2 commits July 18, 2025 22:47

Add enum for type handling of duration values

c254b15

Rename enum to TimeValue

10608e6

raynelfss reviewed Jul 21, 2025

View reviewed changes

Implement From trait, ensure conversion to integer on case to case ba…

e7c4810

…sis per node

raynelfss reviewed Jul 22, 2025

View reviewed changes

phalakbh added 2 commits July 23, 2025 17:45

Modify TimeValue to support arithmetic and max ops; update scheduling…

8cc9893

… to use TimeValue throughout.

Replace enum with TimeOps trait for improved type flexibility

fb05c3d

raynelfss reviewed Aug 6, 2025

View reviewed changes

Remove from_u64 method from TimeOps trait; Refactor code to create op…

ef29117

…_durations only once.

raynelfss previously approved these changes Aug 6, 2025

View reviewed changes

raynelfss enabled auto-merge August 6, 2025 17:54

raynelfss added this pull request to the merge queue Aug 6, 2025

raynelfss removed this pull request from the merge queue due to a manual request Aug 6, 2025

Add back documentation example; Update node_duration argument in docs…

1d04fc0

…tring

phalakbh dismissed raynelfss’s stale review via 1d04fc0 August 6, 2025 19:14

raynelfss approved these changes Aug 6, 2025

View reviewed changes

raynelfss enabled auto-merge August 6, 2025 19:22

raynelfss added this pull request to the merge queue Aug 6, 2025

Merged via the queue into Qiskit:main with commit e9df76a Aug 6, 2025
26 checks passed

github-project-automation bot moved this to Done in Contributor Monitoring Aug 6, 2025

	return Err(TranspilerError::new_err("Duration must be u64 or f64"));
	return Err(TranspilerError::new_err("Duration must be int or float"));

		let mut node_start_time: HashMap<NodeIndex, f64> = HashMap::new();
		let mut idle_before: HashMap<Wire, f64> = HashMap::new();

		let mut op_durations_int: Option<HashMap<NodeIndex, u64>> = None;
		let mut op_durations_float: Option<HashMap<NodeIndex, f64>> = None;

Fully port ALAPScheduleAnalysis to Rust #14664

Fully port ALAPScheduleAnalysis to Rust #14664

Uh oh!

Conversation

phalakbh commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Details and comments

Uh oh!

qiskit-bot commented Jun 24, 2025

Uh oh!

coveralls commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Test Coverage Report for Build 16786305064

Warning: This coverage report may be inaccurate.

Details

💛 - Coveralls

Uh oh!

raynelfss left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raynelfss left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raynelfss left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

phalakbh commented Jul 18, 2025

Uh oh!

raynelfss left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raynelfss left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

phalakbh commented Jun 24, 2025 •

edited

Loading

coveralls commented Jun 24, 2025 •

edited

Loading