Newsgroup: it.comp.lang.perl
Titolo: sysread - STDOUT

sto usando questo metodo (trovato su google) per scaricare un file zip :
while (sysread(FILE, $buf, 1024)) {    syswrite(STDOUT, $buf,
length($buf));}
mi chiedevo se e' il modo migliore, in particolare "1024" puo' essere
modificato?... Puo' essere convniente?
Grazie 1000.
oxy

 Grazie 1000.
Prego,
Nids

 dell'ultima iterazione)
Questo lo so, lo sto usando...   mi chiedevo se possibile e cosa succede
modificando il num. caratteri, perche' proprio 1024?
Ciao

modificando il num. caratteri, perche' proprio 1024?
E` un bel numero intero. Non c'č sostanzialmente altro motivo. Puoi mettere
il numero che vuoi: tutti i numeri sono uguali, anche se alcuni sono piů
uguali di altri (a priori perň č difficile dire quali).
Ci sono evidentemente di mezzo considerazioni oggettive, legate
all'allocazione della memoria, alla dimensione dei cluster sul disco, ecc.
per cui usare alcuni valori puň migliorare leggermente le prestazioni, ma le
condizioni sono cosě variabili che l'unico modo attendibile č fare delle
prove pratiche.
Ciao.

 prove pratiche.
io credo che 1024 sia scelto solo perché 1024 bytes (caratteri) fanno 1kb,
quindi viene trasferito 1kb alla volta... magari è utile se man mano si
vogliono
contare i kb trasferiti.
In download va bene, ma dalle varie prove fatte in passato, ho capito che in
upload (via ftp, usando in parte Net::Ftp) è meglio usare 1: un byte alla
volta.
Capita che su file come mp3, testi, gif, jpeg va tutto bene, mentre su altri
file come .exe, .zip ecc. si perde qualche byte e il file trasferito risulta
corrotto. Ciò potrebbe essere dovuto anche alla differenza dei filesystem
usati sul server e sul client. Mettiamo il caso di un server Win2K (NTFS) e
un client Win98 (FAT32): sulle dimensioni del file uno restituisce un valore
e l'altro __potrebbe__ (non conosco le origini di questa casualità)
riportare un valore diverso. Ecco perché eseguendo un upload da una macchina
Win98 a 1024 bytes alla volta su una macchina WinNT, e poi riscaricando il
file (via http, normalmente) si potrebbe trovare il file corrotto, con
qualche byte in meno. Invece, trasferendo 1 byte alla volta va meglio.
Ma sono tutte supposizioni, le mie.
Ciao,
Guido.

 quali).
In informatica le potenze di 2 sono decisamnte cittadini privilegiati 
nella repubblica dei numeri interi.
-- 
Saluti,
Giancarlo

 nella repubblica dei numeri interi.
questo lo avevo capito:)...
Premesso che passo uno zip tramite http ad un'applet java,   ora sto
provando cosi:
while (<FILE>) { print; }
mi sembra vada meglio, ma non sono nemmeno tanto sicuro, anche prima non
c'erano problemi.
Ma  in questo caso dove non e' specificato nulla come funziona?.. Quanti ne
vengono trasferiti?
Grazie
Ciao
oxy

 Ciao
Ma se ti diverti a implementarti tutto da solo quel 1024 dovrebbere essere
moificato con un compromesso tra l' mtu della tua rete e la grandezza delle
pagina sul disco (che tipicamente e' di 4096). Compromesso sbilanciato dalla
parte della mtu in quanto:
1. presuppongo che il tempo di transferimento dati tra la memoria e il disco
sia piu' basso di quello per trasferire dati della tua rete
2. i dati vengono inseriti prima in memoria e poi scaricati sul disco a
chiusura del file descriptor.
ciao,
Nids
ps: fossi in te userei un modulo gia' fatto: e' la filosofia perl quella di
scrivere applicativi nel piu' breve tempo possibile, e poi perche',
personalmente, odio reinventare la ruota tutte le volte che programmo.

 personalmente, odio reinventare la ruota tutte le volte che programmo.
Sai che non ho capito bene il tuo discorso!?... Hai letto l'ultimo mio
post?..
cmq grazie
Ciao

vengono trasferiti?
In questo caso, funziona per caso. Viene letta e stampata una "riga" alla
volta. Ora, siccome il formato zip è un formato binario, non suddiviso in
"righe", che senso ha parlare di "righe"? L'unica speranza è che, qui e là
nel file, ci sia per caso qualche sequenza "\r\n" (o "\n"), così che la
lettura termina lì. Altrimenti viene letto e stampato tutto il file, tutto
in una volta. In ogni caso, non è possibile dire a priori "quanti ne
vengono trasferiti" e, quel che è peggio, neppure se ci sarà a disposizione
abbastanza memoria per leggere tutto il contenuto del file.
Ciao.

 post?..
scusate se mi intrometto, ma... oxy... sai che forse non hai capito bene
nemmeno come potresti utilizzare perl? :-)
I moduli sono fatti apposta per essere utilizzati e RI-utilizzati, proprio
per evitare di reinventare la ruota. Il suggerimento che tutti ti stanno
dando è proprio "usa i moduli"!
ciao
--
-.. --- -- .. --.. .. ---
-.. . -- .. -.-. .... . .-.. .. ...

 abbastanza memoria per leggere tutto il contenuto del file.
Cosa intendi per memoria disponibile?
Forse funziona meglio proprio perche' viene stampato tutto il file
contemporaneamente?... (i file vanno da 1 a 50 kb circa )
Ciao

 dando è proprio "usa i moduli"!
A parte il fatto che ho  un po' di problemi con i moduli... (come dovresti
sapere visto l'aiuto datomi  precedentemente con gli zip) a meno che siano
inclusi nell'istallazione classica... ma non capisco a cosa ti riferisci
?... Per leggere un file zip e mendarlo nel STDOUT  dovrei usare un
modulo??..
Ciao


per quanto riguarda i moduli... guardati perldoc -q modules e magari ti
farai un'idea più precisa della cosa.
Comunque, sinceramente non capisco PERCHÉ tu debba servire un file zip
attraverso un cgi invece che lasciarlo servire direttamente dal server
Apache, o semplicemente fare un redirect e mandare il client all'url del
file zip. Ci potrebbero essere buone ragioni per farlo fare a un cgi, però,
non credo che al tuo livello di conscenza della materia, tu sappia nemmeno
individuarne uno, quindi... perché non indirizzi il client direttamente
sull'url del file?


scusa... mi è scappata una 's'
perldoc -q module


 sull'url del file?
Be' sono ignorante in Perl e in informatica in generale  (e non solo :)...
ma non sono idiota... i motivi sono diversi... primo il file non esiste ma
viene creato al volo come da richiesta del client... secondo il client non
ha i permessi per accedere... Pero' volendo forse potrei anche farlo...  ma
non so se sia conveniente un redirect... se un redirect e' come
un'interrogazione normale questo da solo puo' far perdere uno-due secondi (o
no?)  annullando quasi il vantaggio dello zip che gia' aiuta poco
considerano la nomale compressione del modem (pero' qualcosa   aiuta,
provato!),  considerando che questo zip viene creato al volo dal cgi
stesso..  mi conviene fare un redirect ?... Ma poi considerando che la
richiesta viene da inputStream di un applet il redirect  funzionerebbe ??...
Ciao:)

 richiesta viene da inputStream di un applet il redirect  funzionerebbe
??...
perché invece di chiedere non provi? le mie erano solo idee alternative ad
un'operazione che secondo me dovresti poter evitare
ciao


 un'operazione che secondo me dovresti poter evitare
perche' sono in arretrato di un mese sulla mia tabella di marcia.. e cosi'
come ora funziona perfettamente, non vedo come un redirect possa migliorarne
il funzionamento... e' sicuramnte piu' veloce la lettura di un file appena
creato che probabilmente viene scritto/letto solo virtualmente.. in quanto
credo che il sistma (se ' un po' furbo)  lo dovrebbe tenere in memoria...
semmai dovrei interessarmi di come usare i file tmporanei, so che
esistono... ma non ho  il tempo per cercare come funzionano, se funzionano
senza moduli aggiuntivi...
La mia domanda all'inizio di questa discusione era solo una curiosita'...
Ciao:)


contemporaneamente?... (i file vanno da 1 a 50 kb circa )
Dipende da che cosa intendi per "funziona meglio". Certo, è probabile che ci
metta meno tempo a leggere il file tutto in una volta, piuttosto che a
pezzetti. Un'altra differenza è che sysread e syswrite potrebbero usare
delle funzioni diverse da quelle usate da read e print.
Ciao.

 vengono trasferiti?
il problema di questa soluzione sta nel fatto che il programma legge una
riga alla volta cioe' fino a quando non trova un delimitatore ( di solito
\n ). Stai  attento ai problemi di overflow del buffer di lettura in quanto
non ne hai il controllo come nella sysread in cui lo fissavi a 1024.
Ciao,
Nids

non ne hai il controllo come nella sysread in cui lo fissavi a 1024.
A parte questo, se proprio si deve leggere un file tutto in una volta, tanto
vale farlo in modo formalmente conseguente, piuttosto che affidarsi alla
lotteria delle "righe" in un file binario:
    {
      local $/;
      open FILE, "< un_file.zip";
      binmode FILE;
      $var = <FILE>;
      close FILE;
      print $var;
    }
Ciao.

Come già detto da Giovanni con parole più tenere, leggere un file binario a
righe è semplicemente una cazzata. (PUNTO)


     }
che scritto "in a fancy way" potrebbe essere:
open _ or die $^E;
binmode _;
print do{local $/; <_>}
(dove $_ contiene il nome del file)
Tra l'altro ricordarsi che il binmode() è MOLTO importante (perldoc -f
binmode).
Comunque - oxy - sparare un file tutto di un fiato, magari va bene con files
piccoli, ma è una cazzata di programmazione tremenda! Un code ben fatto
dovrebbe essere un indipendente dal contesto, perché se un giorno deciderai
di riutilizzarlo per inviare files di 200Mb, non dovrai riscriverlo
miseramente!


 righe è semplicemente una cazzata. (PUNTO)
grazie ragazzi.... io manco sapevo che lo stavo leggevo a righe... avevo
trovato quell'esempio su google proprio per un zip... e infatti poi veniva
corretto nel  sysread (senza spiegazioni)... ma nei miei test il primo
metodo era piu' veloce.
Ora seguiro i vostri consigli
P.s il bimode lo uso :-)

 (dove $_ contiene il nome del file)
azz... io di sto codice non capisco una mazza... meglio il precedente,
quello lo conosco.
Pero' e' forte sto Perl :-D
Ciao
Grazie:)

 E di questo cosa mi dite:
  print "Content-type: application/octet-stream\n";
  print "Content-disposition: attachment; filename='file.zip'\n\n";
se non ho sbagliato qualcosa nei test pare che funzioni solo  con  quello.
Ciao

 righe è semplicemente una cazzata. (PUNTO)
Mi spiace deludere i vostri convincimenti... ma nella vita a volte aiuta  di
piu' l'ignoranza perche' non preclude strade considerate sbagliate dai
convincimenti generali... :-D
cosi :  while (<FILE>) { print; } funziona perfettamente!
cosi : $var = <FILE>;  close FILE;  print $var;
ottengo :
java.io.EOFException: Unexpected end of ZLIB input stream
java.util.NoSuchElementException
PUNTO! :)))

Sei un pirlotto PUNTO! :-)
Cerca di capire se proprio proprio è sbagliato il concetto di chi ti ha
suggerito il code o se invece hai solo fatto una cazzata trascrivendolo!
così
$var = <FILE>;  close FILE;  print $var;
stampa UNA riga
devi undefinire $/ perché ti ci metta tutto il file! Infatti "Unexpected end
of ZLIB input stream" vuol proprio dire i dati sono finiti prima di quello
che si aspettava!


 Pero' e' forte sto Perl :-D
già ;-)


  print "Content-disposition: attachment; filename='file.zip'\n\n";
Come già detto, per queste cose c'è it.comp.www.cgi. Io, a buon diritto,
non so nulla di cgi.
Ciao.

PUNTO! :)))
Hai sbagliato qualcosa nella trascrizione. Ma anche se non avessi sbagliato
nulla, e il codice così come l'ho postato io non funzionasse, la strada
giusta è quella di cercare di capire perché non fa quello che penso di
avergli detto di fare.
In generale, quando si usa un linguaggio, naturale o formale che sia, il
tentativo da fare, io credo, è quello di esprimere quello che si vuol dire
nel modo meno ambiguo possibile: se, una volta, hai chiesto "dove vai?" e
ti ho risposto "porto cipolle!", che, guarda caso, era proprio quello che
volevi sapere, non vuol dire che adesso, per sapere che cosa porto, mi devi
chiedere sempre "dove vai?". Altrimenti, una di queste volte potrei
stupirti, rispondendo "vado a Bitonto!".
Ciao.

> ... rispondendo "vado a Bitonto!".
...che non si deve confondere con bi-tonto :-)


ragazzi non si puo' nemmeno scherzare?... e che cakkio... :)
Ora devo sospendere l'argomento... alla prossima... confido nel vostro
aiuto.
Ciao
Oxy