Quali sono gli svantaggi dell'uso del debugger Perl rispetto a un REPL reale come Devel :: REPL?

Io di solito uso perl -de 42 per ottenere una shell Perl interattiva. Ho visto Devel::REPL e ho visto alcuni blog come http://www.xenoterracide.com/2010/07/making-repl-usable.html che spiegano come è possibile migliorare Devel::REPL con i plugin, ma non li ho ancora usati.Quali sono gli svantaggi dell'uso del debugger Perl rispetto a un REPL reale come Devel :: REPL?

È troppo brutto usare il debugger come shell interattiva? Perché?

Nota: gli svantaggi menzionati in questo PerlMonks node erano limitazioni dell'utente, non del debugger Perl.

Dove posso trovare ulteriori informazioni su Perl REPL?

Devel :: REPL è pronto per le luci della ribalta?

UPDATE: ho accettato la risposta del Pedro, perché ha risposto alla domanda che ho chiesto, ma ancora vorrei sapere quando e perché (se presente) l'uso del debugger Perl come una shell interattiva è una cattiva idea rispetto a una delle implementazioni REPL di Perl. E quale Perl REPL preferisci?

fonte

2010-09-07 Pablo Marin-Garcia

Oltre PDL2 (la shell interattiva Pdl che utilizza Devel :: REPL sotto il cofano) ho visto un altro REPL per Perl: [Carpa :: REPL] (http: //search.cpan. org/perldoc? Carp :: REPL) –

Uno svantaggio di perl -d è che le variabili lessicali escono immediatamente dall'ambito. Esempio:

DB<1> my $p = 123; 

DB<2> print $p; 

DB<3>

Da perldebug:

nota che detto eval è vincolato da un ambito implicito. Di conseguenza, qualsiasi nuova variabile lessicale introdotta o qualsiasi contenuto del buffer di acquisizione modificato è persa dopo la valutazione. Il debugger è un ambiente simpatico per imparare Perl, ma se lo si sperimenta interattivamente usando il materiale che dovrebbe essere nello stesso ambito di , inseriscilo in una lente, inserirlo in una riga.

fonte

2010-09-07 23:52:46

Beh, dovrei dire che, in risposta alla domanda "quali sono gli svantaggi dell'uso del debugger perl rispetto a un REPL reale come Devel :: REPL?", le variabili lessicali non lavorare è una risposta. In realtà, causa molti problemi, non solo con le funzionalità 5.10. Il principale è, * non è un REPL reale *; non puoi fare sviluppo interattivo su di esso. –

beh, lo sto usando sempre senza restrizioni e con variabili globali. Non sto facendo grandi cose, solo testando le API ritorni oggetti o manipolando file ed è più semplice disegnare i oneliner in un REPL che per tentativi ed errori nella shell. Detto questo, il mio problema con l'ambito non sono le variabili ma le funzioni perl 5:10 che non sono disponibili perché il problema dell'ambito vedi [Come utilizzare le funzionalità di perl 5.10 all'interno del debugger?] (Http: // stackoverflow. it/questions/3539710/how-to-use-perl-5-10-features-inside-the-debugger) –

dal punto di vista di _real REPL_ e come ho formulato la domanda hai completamente ragione riguardo all'ambito della variabile. Ma questa era una limitazione che già conoscevo e non influenza il mio normale utilizzo interattivo così * nel mio caso * questo non è un problema per passare a un REPL reale, ma non essere in grado di usare le caratteristiche di perl5: 10 * IS *. Ero più interessato a sapere se c'erano limiti nell'uso della memoria, nell'efficienza, ecc. Non ho ancora accettato la tua risposta ;-) (nonostante sia corretto), perché volevo attirare altre risposte che potessero concentrarsi su altre differenze più importanti per me. –

Invece di utilizzare il debugger e perdere le caratteristiche, tendo a usare solo

perl -wnE'say eval()//[email protected]'

Ho usato Devel :: REPL e piace, ma proprio mai siamo abituati ad usarlo.

Un vantaggio dell'utilizzo del debugger è la possibilità di arrestare $DB::single=1 e il passaggio singolo in un determinato punto.

fonte

2010-09-08 01:12:27 ysth

Grazie, non sapevo questo trucco, +1 perché è un buon modo di avviare una calcolatrice ;-) ma come shell interattiva non è molto utilizzabile: nessuna cronologia, nessuna lettura, nessuna opzione 'm' per vedere quali metodi è possibile chiamare in un oggetto, è necessario utilizzare Data :: Dumper invece x 1, x 2 ecc., nessuna espansione scheda per vedere le variabili utilizzate .... –

@Pablo: [rwwrap] (http://utopia.knoware.nl/~hlub/rlwrap/#rlwrap) fa miracoli per la cronologia e il supporto readline. –

@Pedro: grazie, questo è uno strumento piacevole da sapere. –

Entrambi hanno obiettivi diversi. Il debugger è ottimizzato per il debug uno script/programma Perl già scritto. Considerando che un obiettivo primario REPL è fornire un feedback rapido del linguaggio ed è ottimizzato per l'input interattivo (degli sviluppatori).

Ad es. Se faccio la seguente nel debugger Perl:

DB<1> for my $x (1..10) {

ottengo un errore Missing right curly or square bracket at (eval 5)....

Mentre con Devel::REPL Permette dati su più righe:

$ for my $x (1..3) { 
> say $x; 
> } 
1 
2 
3

Raccomando Devel::REPL e con i plugin aggiuntivi diventa uno strumento di sviluppo utile per avere in esecuzione accanto il vostro editor.

/I3az/

fonte

2010-09-09 19:49:18 draegtun

Penso che con i plugin corretti Devel :: REPL sarebbe uno strumento utile. È più bello colpire solo rispetto a "\ " alla fine delle linee in esecuzione nel debugger. –

ho scoperto che PDL2 (la shell interattiva per PDL) sta usando ora Devel :: REPL e caricare un sacco di plugin: $ PDL2 Perldl2 Shell v0.004 Loaded plugin: Comandi Completamento CompletionDriver :: Parole chiave CompletionDriver :: LexEnv CompletionDriver :: Metodi DDS FindVariable Storia interrupt LexEnv MultiLine :: PPI NiceSlice PDLCommands Pacchetti PrintControl ReadLineHistory . SIMPATICO!! –

Sì 'pdl2' usa' Devel :: REPL' se è installato altrimenti cade a 'perdl' (REPL originale di PDL). 'PDL' e' Devel :: REPL' sono davvero un bel matrimonio !! – draegtun

Quali sono gli svantaggi dell'uso del debugger Perl rispetto a un REPL reale come Devel :: REPL?

risposta

Problemi correlati