surprising behavior with -instrument and godep
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- go
- Ambito
- cli, developer-experience, devtools
Direzione di ricerca
Inizia con il comando godebug run e la gestione di -instrument, quindi riproduci il caso di workspace godep descritto nell’issue. Per considerare il lavoro completato, è necessario decidere se avvisare dei package che non sono importati, rimuovere il flag o migliorarne il comportamento, documentando o testando il compromesso in termini di prestazioni.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I am debugging a program that has a dependency on package foo, and I want to step into function calls in foo. So I run:
$ godebug run -instrument=foo myProg.go
godebug runs without complaint. Yet, to my surprise, I still can't step into foo. Why? Because I had forgotten that I was using godep. I would have been fine if I had instead run:
$ godebug run -instrument=my/package/name/Godeps/_workspace/src/foo
It would be nice if godebug caught this for me. At a minimum, it could have noticed that I didn't import package foo anywhere, and warned me that it was useless to pass that package in the instrument flag.
Alternatively, maybe we should get rid of the -instrument flag entirely. Having it sacrifices some usability for performance, but I don't understand the tradeoff very well. How much performance would we lose by instrumenting everything? Can we make that better? How often does the flag cause surprising behavior?
- Lingua principale
- Go
- Stelle
- 2.5k
- Fork
- 102
- 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 mailgun/godebug
-
question a bout debugerAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 10/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
-
Website not updatedAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 35/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
-
syntax highlightingAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
Tutte le issue di mailgun/godebug
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
txn2/mcp-data-platform#2493 ·
I maintainer di solito rispondono entro 1 giorno
-
area/docs framework/hugo help wanted language/markdown
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:other issue-rating: 🦞 diamond lobster no-stale P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
openclaw/crabbox#3060 · 1 commento · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
radius-project/radius#13698 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno