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: Thu, 26 Mar 2015 04:00:39 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

fatta la versione compatta: l'ho chiamata "lite".
funziona con l'opzione `-l, --lite`

va un po' testata perché, come nel caso dell'avvio dell'editor e
dell'interfaccia interattiva, ma in un contesto totalmente
diverso, è necessario ammutolire l'output di background.
Purtroppo, consuma almeno il doppio in cpu, perché fa circa il
doppio dei controlli/lettura file temporanei ecc. con awk (in
media, uno ogni 1,5 secondi circa). Questo avviene perché è
necessario sganciare l'output lite dai processi che ricavano gli
url dal web (le estensioni con i countdown e altre perdite di
tempo, che renderebbero l'output lite molto peggiore...) . In
pratica, è necessario sdoppiare zdl, proprio come quando si avvia
l'interfaccia interattiva con M-i (ma quella interattiva refresha
i dati e lo schermo ogni 15 secondi, mentre quella lite ogni 3,
come i processi sottostanti: per questo, in media i controlli
sono effettuati ogni 1,5 secondi -senza tenere conto dei
countdown e le ricerche nel web, che allargano questa finestra
temporale ma la riempono di altre cose)... mi sembra di scrivere
percorrendo un circolo :/
è tardissimo e sto crollando dal sonno...


Il 25-03-15, 23:19, Gianluca Zoni <address@hidden> ha scritto:
> Il 25-03-15, 22:31, claudio <address@hidden> ha scritto:
> > Gianluca, immaginavo che sarebbe stata una cosa complicata ... :D
> > Io ho fatto una prova con l'accetta, tagliando parzialmente
> > DLstdout_parser.awk e modificando la chiamata ad Axel con l'opzione
> > -a e la rimozione della redirezione. Era solo per vedere com'era con
> > la barra fissa di Axel e ho provato solo a scaricare un video
> > youtube (che veniva scaricato però più volte, credo perchè il
> > temp
> 
> veniva scaricato più volte perché zdl non sapeva
> se il download era stato completato (magari pensava che si fosse
> interrotto) non potendo leggere il file di output. Se fosse stato
> creato lo stesso ridirezionando con "tee" (che stampa anche sullo
> schermo oltre che nel file), zdl non avrebbe comunque potuto
> leggere i dati perché è stato fatto per un altro output
> 
> > con i link non veniva più aggiornato). Ho capito subito che sarebbe
> > stato complicato, almeno per me, l'ho buttata lì sperando che tu che
> > ne conosci a fondo tutti i meccanismi potessi trovare una soluzione.
> 
> hai fatto benissimo a provare e a proporre!
> la complicatezza è di due tipi: tecnica, perché è
> dispendiosissima di risorse l'estrazione dei dati da quegli
> output  e anche incasinata di per se. Poi c'è il casino dovuto al
> fatto dei download di più file, che non si sa come piazzarli
> nello spazio del terminale
> 
> > Comunque l'idea della 'modalità supercompatta' mi sembra un'ottimo
> > compromesso. Sono d'accordissimo.
> 
> ci stavo lavorando proprio adesso e sono proprio curioso di
> vedere cosa salterà fuori :) (l'idea di comporre la stessa barra
> di progresso con il nome del file dentro, però, mi sta facendo
> impazzire. Ma devo riuscirci!)
> 
> 
> 
> > 
> > 
> > 
> > Il 25/03/2015 20:47, Gianluca Zoni ha scritto:
> > >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:DLstdout_parser.awk
> > >- 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
> > >
> > 
> > -- 
> > 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]