Debugging: Best Practices
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Documentazione
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- documentation
Direzione di ricerca
Inizia con il controllo documentato tmsmt ops.pddl facts.pddl e le chiamate Python tm.bind_scene_state e tm.bind_goal_state. Traccia come si combinano i dati della scena, :init e -q, quindi documenta controlli riproducibili e l'output previsto dello stato completo/debug; il lavoro è completato quando un nuovo contributore può diagnosticare un risultato senza piano senza usare Lisp.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hi,
I wanted to know whether there are some hints on how to best debug a newly defined problem that doesn't work as expected (i.e., no plan was found).
I figured out that the pure task domain can be verified via tmsmt ops.pddl facts.pddl which is a first step.
But once this is done, I would like to get more insight into the full blown geometric problem. For example: Is it possible to output the initial and goal state conjunction? The initial state depends on the scene file, the optional task problem definition (:init) and the initial state (-q). I'm not sure I fully understand what happens when competing facts are defined in these different sources.
I'm also using the python interface and first thought that outputting the return value of tm.bind_scene_state and tm.bind_goal_state might give all necessary information but I realized that these lists are not the full state (at least the planner even fails when both are identical -- although there should be a trivial solution).
Any hints on how to debug (without going the LISP way)?
- Lingua principale
- Common Lisp
- Stelle
- 59
- Fork
- 13
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di KavrakiLab/tmkit
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
KavrakiLab/tmkit#18 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
KavrakiLab/tmkit#17 · 4 commenti ·
-
Conflicting options in run scriptForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 45/100
KavrakiLab/tmkit#16 · 1 reazione ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 20/100
KavrakiLab/tmkit#14 · 4 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
KavrakiLab/tmkit#11 ·
Tutte le issue di KavrakiLab/tmkit
Issue simili
-
tech-debt
Difficoltà 2/5 Mezza giornata Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
バグ・誤り・不備
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
lean-ja/lean-by-example#2641 ·
-
agent-butler-finding chore
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
jordansmall/spindrift#5575 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
IntersectMBO/developer-experience#363 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
stellar/stellar-docs#2921 ·
I maintainer di solito rispondono entro 1 giorno