zdl-devel
[Top][All Lists]
Advanced

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

Re: [zdl-devel] ottimizzato ZDL


From: claudio
Subject: Re: [zdl-devel] ottimizzato ZDL
Date: Fri, 27 Mar 2015 01:59:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

OK, provato adesso e mi piace.
C'è solo un piccolo problema che non capisco se è voluto. La barra di progresso sovrascrive il nome del file. Ora però sono troppo stanco, lo provo più a fondo domani.



Il 26/03/2015 16:30, Gianluca Zoni ha scritto:
ciao,
trovato il modo di ridurre l'uso della cpu alla metà per --lite
(non ci avevo pensato ieri notte perché ero fuso)


Il 26-03-15, 04:00, Gianluca Zoni <address@hidden> ha scritto:
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


--
c l a u d i o
address@hidden



reply via email to

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