zdl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [zdl-devel] ottimizzato ZDL


From: Gianluca Zoni
Subject: Re: [zdl-devel] ottimizzato ZDL
Date: Wed, 25 Mar 2015 20:47:21 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

claudio,
mi è venuta in mente un'idea un po' malsana...
si potrebbe creare una "modalità compatta", che terrebbe insieme
entrambe le tue esigenze (ma con un output a là zdl, anche se
modificato)

L'idea è questa: 
- niente informazioni sui processi di estrazione
  degli url dai servizi ecc., proprio come quando avvi la modalità      
  interattiva con <M-i> e tutto il lavoro da minatore del web
  viene silenziato

- interazione e avvio identici alla "modalità normale/in stdout"
  (con la readline e M-i, M-e, M-q, M-k che funzionano allo
  stesso modo) 

- dopo l'avvio con M-x <Invio>, la pagina viene ripulita e
  compaiono solo le barre di progresso con sopra il nome del file
  (il nome in primo piano, mentre con i colori dello sfondo la
  barra). I dati a sinistra e a destra rimangono invariati.

- le barre verrebbero accatastate l'una sull'altra, senza alcuno
  spazio intermedio e il tutto infilato in un box con le info
  principali sulle due strisce in alto e in basso

- il tutto verrebbe refreshato ogni tot secondi, per esempio 3 o
  4

che te ne pare della modalità supercompatta?
:)



Il 25-03-15, 20:24, Gianluca Zoni <address@hidden> ha scritto:
> ciao,
> visto solo ora la tua email...
> 
> Il 25-03-15, 16:28, claudio <address@hidden> ha scritto:
> > Ho fatto una prova in modo piuttosto grezzo e il risultato mi è
> > piaciuto molto. La barra alternativa di Axel è molto bella con
> > l'avanzamento dei singoli spezzoni e il download risulta leggermente
> > più veloce perchè ovviamente zdl non deve continuamente scrivere e
> > leggere dalla temp. L'ideale, come accennavo sopra, sarebbe
> > anche togliere tutte quelle informazioni non essenziali, come 'Url del
> > file', 'Link da processare', etc., che il più delle volte sono
> > stringhe lunghissime e incomprensibili. Si potrebbe inserire una
> > nuova opzione --default-progress che permettesse di visualizzare le
> > barre di progresso di Axel e Wget al posto di quella personalizzata.
> > E naturalmente anche un'opzione --verbose che invece abiliterebbe la
> > visualizzazione di un outpup più descrittivo, con le varie
> > informazioni su 'Url', 'Link' e così via. Il tutto naturalmente
> > anche configurabile nel file zdl.conf. Che ne pensi?
> > 
> 
> zdl non deve leggere gli output dei downloader per stampare a
> schermo. Infatti, per la stampata dei box con le barre, usa i dati
> già letti e filtrati da awk, inseriti in array specifici, che
> servono a controllare che tutto proceda come dovrebbe:
> quanti download sono attivi e se sono attivi, controllo se axel
> si è inceppato, rilevamento di file omonimi e decisione su cosa
> fare, controllo se il download è completato e quindi il link va
> tolto dalla coda di download, gestione di quasi tutto quanto....
> (il grosso del lavoro è svolto dalla funzione "data_stdout" nel
> file libs/DLstdout_parser.sh che usa libs/DLstdout_parser.awk:
> oltre a filtrare i dati, agisce anche sull'intero sistema, per
> esempio con la funzione check_stdout e producendo un output che
> assegna valori a variabili ed array sia della bash, che lo esegue
> con "eval", sia delle successive chiamate di awk per la stampa)
> 
> tutte informazioni che vanno comunque estratte ed elaborate (zdl
> scrive nei file degli stdout solo le prime righe, poi li legge
> soltanto): 
> togliere la stampata a schermo così com'è non renderebbe il
> programma più veloce di quanto la bash e awk non impieghino per stampare.
> Però mi interessa la tua proposta. In principio ho cercato di
> usare l'output alternativo di axel ma non sono riuscito a
> gestirlo. Il problema è dato anche dal fatto che ZDL può
> scaricare più file alla volta e non ho idea di come infilarci più
> output alternativi di axel nello stesso momento...
> 
> per esempio,
> dopo aver avviato zdl normalmente, è possibile farlo lavorare
> silenziosamente "dietro" la modalità interattiva, pigiando M-i, 
> che, cancellando la
> pagina ogni volta e riscrivendola (ogni 15 secondi oppure quando
> si pigia un tasto) ristampa la barra "sul posto". Ma il "refresh"
> di un'intera pagina è fastidioso (per questo l'ho arbitrariamente
> fissato a ogni 15 secondi), soprattutto se ci sono tanti
> download (e se occupano "più pagine" è peggiore) e più lento su
> cygwin... ma se ci sono più download alla volta, ho paura che, per
> avere l'effetto di una barra che si allunga sul posto, sia
> necessario stampare tutta la pagina (soprattutto se i download
> non stanno tutti nello schermo: 15 download, magari 10 non
> attivi...) 
> 
> poi c'è un'altra questione: zdl scarica anche con wget e
> rtmpdump/curl, ognuno con un output diverso... immaginali da
> gestire insieme, in download che avvengono insieme: mi viene il
> mal di testa solo a pensarci (non tanto per questioni di gusto,
> ma per come gestirli)
> 
> hai scritto di aver fatto un esperimento: se hai suggerimenti
> tecnici, anche solo abbozzati, potrei rifletterci e provare anch'io
> 
> Per ora c'è anche la possibilità di avviare zdl in modalità
> demone, che se ne sta zitta in un altro universo. Può essere
> avviata anche da 'zdl -i': la prima può fungere da server mentre
> la seconda da client. Produce tutte quelle informazioni perché in
> effetti mi sono trovato ad averne bisogno. Ma si può esempre
> uscire da quella interattiva e lasciare il demone avviato
> 
> Si protrebbero comunque distinguere modalità con "verbosità"
> diverse, anche se non dovessimo riuscire a gestire gli output
> infernali di wget e axel. Intanto, negli ultimi tempi ho già
> eliminato un po' di verbosità... però alcune info (per esempio
> che sta per processare un link) servono a far capire all'utente
> che zdl non si è incantato e non rendono davvero più lento il
> programma 
> 
> Ah! c'è una cosa fondamentale da dire: i dati degli output vanno
> comunque estratti! quindi, anche stampandoli+salvandoli con
> programmi come "tee", poi c'è un enorme problema di estrazione da
> output folli come quello "normale" di wget e quello "alternativo"
> di axel (con file infinitamente più lunghi, perché aggiornati a
> velocità folle, con barre "scritte sul posto"... su cui
> impazzivo nei primi tempi e con un output totalmente
> diversi... quindi con gli script appena scritti per awk da rifare =°°D)
> 
> ai primordi, quando zdl era uno script che si limitava ad avviare
> i download in terminali separati senza gestirli (e quasi sempre
> rimanevano incompleti, anche perché axel mi si pianta quasi
> sempre, soprattutto con grossi file ...e la connessione mi salta
> spesso), questi problemi che ho sollevato non si ponevano e usavo
> l'output degli stessi downloader. Ma adesso... come facciamo? 
> Purtroppo, la stampa di una nuova barra di progresso era
> diventata una necessità (e tanto valeva farla uguale per tutti i
> downloader) per adottare output gestibili, come quelli di
> wget e axel fatti apposta per gli script
> 
> riflettendoci mentre scrivo, forse si potrebbe puntare sull'idea
> di stampare questa barra in coordinate precise (al momento non
> ho idea di come fare) ma, come dicevo, c'è anche il problema
> della possibile fuoriscita dell'output dalla schermata: per
> esempio, la dimensione della finestra potrebbe non bastare in
> altezza (a volte non basta neppure a me che uso sempre i
> terminali a tutto schermo), per via di download multipli o per
> via di download abortiti ecc. 
> 
> che dire? non so...
> se hai un'idea per la messa in pratica della faccenda barra di
> progresso sono in scalpitante attesa
> 
> intanto comincio a vedere cosa si può fare per la verbosità
> multilivello...
> 
> 
> > Il 21/03/2015 19:05, Gianluca Zoni ha scritto:
> > >ciao,
> > >negli utlimi tre giorni ho ottimizzato ZDL ancora di molto:
> > >ho eliminato diversi controlli e cicli incorporandoli nelle
> > >funzioni principali eseguite da awk. Credo anche di aver trovato
> > >il modo di far scaricare con axel i link di youtube: ho notato che
> > >axel, in particolare, ha bisogno di almeno 4 secondi per avviarsi
> > >in modo tale da funzionare correttamente con ZDL (dipende dal suo
> > >output). Per ora ho messo un conto alla rovescia di 4 secondi, ma
> > >potrei aumentarlo
> > >
> > >In questi giorni ho stressato parecchio il programma in
> > >svariati modi, ma "se il peggio può accadere, accadrà
> > >certamente" e c'è ancora un margine di possibilità per eventuali
> > >malfunzionamenti o operazioni trascurate: zdl va rodato e ci
> > >vorrà tempo.
> > >
> > >Si può ottimizzare ancora, ma per ora mi fermo. Mi dedicherò con
> > >calma alla stesura del manuale
> > >
> > >
> > >
> > 
> > -- 
> > c l a u d i o
> > address@hidden
> 
> -- 
> Z O N I N O Z
> Gianluca Zoni
> 
> address@hidden
> http://inventati.org/zoninoz
> http://savannah.gnu.org/users/zoninoz

-- 
Z O N I N O Z
Gianluca Zoni

address@hidden
http://inventati.org/zoninoz
http://savannah.gnu.org/users/zoninoz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]