:recycle: Separate Simulation, Debugging and Diagnostics concerns further
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 20/100
Línea de trabajo
Comienza rastreando las interfaces existentes de debug.h y diagnostics.h, especialmente qué campos de diagnóstico se encuentran en DDSimulationState y qué métodos están en DDDiagnostics. Mapea las responsabilidades propuestas de simulation.h y cómo step-forward y getCurrentInstruction podrían admitir operaciones de más alto nivel. Se considera terminado cuando las tres interfaces y sus implementaciones DD estén separadas con un acoplamiento mínimo a OpenQASM.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What's the problem this feature will solve?
Currently, the debugging backend is separated into two interfaces:
debug.h and diagnostics.h. However, this separation is not perfect.
- For the DD implementation in particular, many diagnostics concerns are still stored in the
DDSimulationStateand only the actual methods and functionalities are located inDDDiagnostics. These fields should be moved
Furthermore, a third simulation interface would make sense. Currently, if we want to change to a new simulation backend, a large number of different functions have to be re-implemented, even though they can be expressed through different functions. For instance, all the "step over", "step out", "run simulation" functions can be expressed using just the "step forward" method and "getCurrentInstruction". It would be nice to separate these so that changing the simulation backend only requires a few functions to be changed.
Describe the solution you'd like
Three interfaces:
debug.h: Contains debugging-related functions, like checking assertions, running up to specific points in the code, or getting the stack tracesimulation.h: Only contains low-level simulation features, like stepping forward, backward, etc.diagnostics.h: Contains all functions related to analysing the program.
Their DD-based implementations should also be separated more clearly, and, if possibly, with only minimal coupling to the actual language used (such as OpenQASM)
- Lenguaje dominante
- C++
- Estrellas
- 21
- Forks
- 8
- Merge medio
- 5 h 17 min
- PR fusionados (30 d)
- 21
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de munich-quantum-toolkit/debugger
-
Dificultad 3/5 1-2 días Aptitud para principiantes 84/100
munich-quantum-toolkit/debugger#469 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 66/100
munich-quantum-toolkit/debugger#468 ·
Los mantenedores suelen responder en 1 día
-
✨ Improve CLI UX: line editing, function-key shortcuts, and help barPosiblemente ocupada @rturrado la tomó hace 32 días. Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
munich-quantum-toolkit/debugger#467 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
munich-quantum-toolkit/debugger#465 ·
Los mantenedores suelen responder en 1 día
-
c++ enhancement help wanted
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
munich-quantum-toolkit/debugger#168 ·
Los mantenedores suelen responder en 1 día
Todos los issues de munich-quantum-toolkit/debugger
Issues similares
-
accessibility good first issue hacktoberfest help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
OpenChemistry/avogadrolibs#3184 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Tracktion/tracktion_engine#475 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
redis/memtier_benchmark#732 ·
Los mantenedores suelen responder en 1 día
-
binding:web core docs p3
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
RunanywhereAI/runanywhere-sdks#1123 ·
Los mantenedores suelen responder en 1 día
-
ai_p3 comp-data-types
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
ClickHouse/ClickHouse#126316 ·
Los mantenedores suelen responder en 1 día