Newsgroup: it.comp.lang.perl
Titolo: problemi nel visusalizzare una gif nel browser: come?

Vorrei visualizzare una figura presa da un file in una pagina web
ho scritto il seguente codice che sembra non
funzionare correttamente (mi da la pagina vuota).
il file scritto è:
#! /usr/bin/perl 
open(PICTURE,"nov.gif");
$gif=<PICTURE>;
print "Content-type: image/gif\n\n";
print $gif;
cosa è che non va?
e se volessi ritardare la visualizzazione, esempio spedire solo un pò di bit
o kbit al secondo?
grazie in anticipo, Mario.

 o kbit al secondo?
una buona ispirazione potrebbe essere:
perldoc -f read
--
perl -MLWP::Simple -e "getprint(' 
http://perl.4pro.net
 ')"

o kbit al secondo?
(Altro deja-vu) chiedi su it.comp.www.cgi, ma la questione, per quel poco
che ne so io, è po' più complessa che "spedire solo un po' di bit al
secondo". Sempre sulla base del poco che ne so io, se è necessaria una
temporizzazione, la soluzione più semplice è che sia il client a farla.
Ciao.

binmode(PICTURE);
binmode(stdout);
print $gif;
BinMode non vuol dire che entra in modalità BinLaden, vuol dire che entra in
modalità binaria. Quindi così considera il file binario e l'uscita binaria.
Quandi la vedi bene.
Ciao

> binmode(stdout);
cos'è?


Mette in binario l'uscita stdout.
Se vuoi definire un file binario usi:
open(file, ">gif.gif");
binmode(file);

 > cos'è?

allora forse vuoi dire:
binmode STDOUT;
e non 'stdout', o qui perl è case insensitive, o mi sono perso qualcosa?
Inoltre: non aderiamo tutti alla convenzione che specifica che i nomi dei
filehandlers dovrebbero essere tutti maiuscoli?


 filehandlers dovrebbero essere tutti maiuscoli?
Booo...a me funziona sempre quando lo metto minuscolo...mai scritto in perl
anche una solo cosettina in maiuscolo.

 anche una solo cosettina in maiuscolo.
non è che assegnare un filehandler minuscolo NON funzioni, solo che
semplicemente va fuori delle convenzioni, e diventa più difficile da
leggere. Inoltre credo proprio che ci siano cose che vanno scritte
maiuscolo, altrimenti non funzionano.... queste sono le prime che mi vengono
in mente:
AUTOLOAD BEGIN END DESTROY SUPER %ENV @ISA %SIG STDIN STDOUT STDERR
__PACKAGE__ __LINE__ __DATA__ __END__
ecc. ecc.
dd


AUTOLOAD BEGIN END DESTROY SUPER %ENV @ISA %SIG STDIN STDOUT STDERR
No, STDIN, STDOUT e STDERR puoi scriverli sia tutto maiuscolo che tutto
minuscolo, ed ha sempre il medesimo effetto (salvo le solite occasionali
sorprese).
Non ho trovato documentazione al riguardo, ma sono sicuro che da qualche
parte c'č.
Ciao.

 sorprese).
sarà, ma secondo me non vale comunque la pena andare contro corrente
assumendosi solo il rischio di incappare in qualche caratteristica chissà
nemmeno documentata, (che magari in una prossima versione potrebbe smettere
di funzionare) a cambio di che? Risparmiare la vernice del tasto shift???
Perché altra utilità non la vedo mica: il code è solo meno leggibile, e
certo non più conciso né rapido né altro.
Comunque rimangono tutti gli altri maiuscoli, nonché la tradizione case
insensitive che mi pare più semplice da ricordare senza eccezioni che con.
Alla fine della fiera, quindi, nonostante io stesso sia sommamente
anti-conformista, per perl almeno credo sia decisamente più sicuro e
conveniente seguire le convenzioni più diffuse piuttosto che tentare di
reinventare una ruota che, per tonda che sia, sarà sempre un po' ovale :-).


sarà, ma secondo me non vale comunque la pena andare contro corrente
Questo è esattamente il punto: qual è il verso della corrente? Nella
documentazione compaiono entrambe le forme; e io, che uso perl da una vita,
sono abituato a scrivere stdout, stdin e stderr: da qualche parte l'avrò pur
preso (la contaminazione col C non vale, perché ho imparato il perl prima
del C). E non c'è obiezione con la convenzione "i filehandle si scrivono in
maiuscolo": gli handle di default sono sufficientemente particolari da
meritare un trattamento distinto (la scrittura in minuscolo potrebbe
evidenziare appunto l'aspetto particolare di questi handle, ed evitare che
si vada in cerca di un open esplicito).
Insomma, personalmente ritengo conveniente rintracciare un riferimento
specifico nella documentazione, prima di esprimere giudizi definitivi.
Ciao.

Va bene. Lo terrò bene a mente la prossima volta. Grazie.
Domizio Demichelis wrote:




***************************************
messaggio inviato tramite HostSearch.it
---------------------------------------
---> 
http://www.hostsearch.it/newsgroup
***************************************

 preso
sarà roba vecchia, però MOLTO vecchia, perché io non l'ho MAI visto in
minuscolo, non solo nella doc, ma nemmeno su Programming Perl 2nd Edition
datata settembre 1996! (né nel contenuto, né nell'indice, né nel glossario!)
Questo mi fa pensare che magari è roba della 4 che funziona per backward
compatibility, però continuo a pensare che è meglio aggiornarsi alle nuove
convenzioni, soprattutto perché se "la Bibbia" non le cita, ormai sono
eresia. :-)


 qualche parte c'č.
perldoc perlop
       The filehandles STDIN, STDOUT, and STDERR are predefined.
       (The filehandles stdin, stdout, and stderr will also work
       except in packages, where they would be interpreted as 
       local identifiers rather than global.)  
MM

eresia. :-)
E quali sarebbero le "nuove" convenzioni? Fidati, in nessun luogo si dice
che si debba usare la forma maiuscola, o che questa sia meglio di quella, o
che sia preferibile dal punto di vista stilistico, o che una sopravviva solo
per compatibilità, o che verrà abbandonata o null'altro.
L'unico riferimento è questo (in perlop):
    The filehandles STDIN, STDOUT, and STDERR are predefined. (The
    filehandles stdin, stdout, and stderr will also work except in
    packages, where they would be interpreted as local identifiers
    rather than global.) 
Francamente, è un po' poco per lanciarsi in battaglie stilistiche e,
tantomeno, crociate in difesa della vera fede.
Anche le "convenzioni" che citi, riguardo ai nomi dei filehandle, è
discutibile che siano le più appropriate; qualcuno potrebbe legittimamente
sostenere che è più giusto riferirsi alle convenzioni su parole chiave e
nomi predefiniti (di questo in fondo si tratta), che sono scritti per lo più
in minuscolo. Insomma, non ci sono proprio gli estremi per tacciare di
eresia nessuno.
Ciao.

 eresia nessuno.
Se non sai dedurre da solo che STDIN, STDOUT, STDERR, e praticamente tutti i
FILEHANDLERs sono sempre scritti tutto maiuscolo in tutta la documentazione
e esempi di perl, e sono adottati dalla
stragrande maggioranza di programmatori allora non sarò certo
io a farti capire che la convenzione esiste ed è ampiamente condivisa!


 wrote in message
news:dd9r0v4dn2phpmdgl...@4ax.com...


basti:
Nessuno dei riferimenti che citi c'entra alcunché con la questione. Ripeto:
il punto non è se "i filehandle (generati esplicitamente) vanno scritti in
maiuscolo" (convenzione che non ho mai messo in discussione), ma quali siano
i nomi predefiniti di standard input, output ed error. Nulla nella
documentazione dice che una forma debba essere preferita all'altra. L'unico
punto, in cui si pone la cosa, brilla per la mancanza assoluta di un
giudizio in merito.
Ciao.

ti evita di doverti ricordare l'eccezione
Tutto quello che è possibile obiettivamente ricavare da quel brano è che
entrambe le forme sono riconosciute, punto e basta. Non è espresso alcun
giudizio, né stilistico né di altro tipo. Tutto il resto sono tue personali
convinzioni e conclusioni, più o meno condivisibili, secondo gusti e
abitudini.
Ciao.

 Nulla nella documentazione ...
"Nulla" a parte il fatto che è esplicitamente detto "The filehandles STDIN,
STDOUT, and STDERR are predefined." mentre le forma minuscola è ammessa
(funziona) solo in package main. :-)))
"Nulla" a parte il fatto che OVUNQUE in perldoc stanno scritti maiuscolo.
"Nulla" a parte il fatto che da tutte le parti lo stesso Larry Wall usa
STDIN, STDOUT e STDERR, e non stdin, stdout, stderr che non usa MAI. In
Programming Perl 2nd edition i famigerati appaiono un numero infinito di
volte negli esempi e specificamente nel testo alle pagine:
13, 140, 166, 169 per STDIN e STDOUT
140, 166, 549 per STDERR
Magari scrivi a Larry Wall, e spiegagli che, anche se LUI stesso usa
scriverlo così dappertutto, per te è comunque una convenzione discutibile.
:-)
Comunque da parte mia chiudo qui questo questo thread, che ormai servirebbe
solo più a te, perché tutti gli altri hanno capito già da un bel po' :-)
