Bonjour , j'ai un souci avec ma fonction suivante :
sub doZip {
my ($fichier,$fichierreg, $nomZip) = @_ ;
open FICHIER, $fichier ;
my $ligne, my $longueur;
my $zip = Archive::Zip->new();
while (<FICHIER>) {
next if (($longueur=length($_)-2) <= 0);
$ligne = "$_";
my @lig = split /\|/,$ligne;
if ($lig[0]=~ m/^\+ .+$/ ) {
my $prog = substr($lig[0],2,length($lig[0])-2);
chomp $prog;
print "\"$prog\"";
warn "Error adding file $prog : $!\n" ;#if
($zip->addFile($prog) != AZ_OK);
}
}
unlink($nomZip);
$zip->addFile($fichier,"$install/$fichier") or warn "Error
adding file $fichier\n";
$zip->addFile($fichierreg,"$install/$fichierreg")or warn
"Error adding file $fichierreg\n";
if($zip->writeToFileNamed($nomZip) != AZ_OK){
die 'write error Zip';
}
}
Le but est de parcourir un fichier et de zipper tous les noms de
fichiers contenus a l'intérieur.
Le souci est que chaque fichier lu admet une Bad file descriptor
Que signifie cette erreur ?
sub doZip { my ($fichier,$fichierreg, $nomZip) = @_ ; open FICHIER, $fichier ; my $ligne, my $longueur; my $zip = Archive::Zip->new();
while (<FICHIER>) { next if (($longueur=length($_)-2) <= 0); $ligne = "$_"; my @lig = split /|/,$ligne; if ($lig[0]=~ m/^+ .+$/ ) { my $prog = substr($lig[0],2,length($lig[0])-2); chomp $prog; print ""$prog""; warn "Error adding file $prog : $!n" ;#if ($zip->addFile($prog) != AZ_OK); } } unlink($nomZip); $zip->addFile($fichier,"$install/$fichier") or warn "Error adding file $fichiern"; $zip->addFile($fichierreg,"$install/$fichierreg")or warn "Error adding file $fichierregn"; if($zip->writeToFileNamed($nomZip) != AZ_OK){ die 'write error Zip'; } }
Le but est de parcourir un fichier et de zipper tous les noms de fichiers contenus a l'intérieur. Le souci est que chaque fichier lu admet une Bad file descriptor Que signifie cette erreur ?
Il manque un close FICHIER à la fin de votre boucle. Vous ne pouvez pas ouvrir un fichier qui est déjà ouvert au premier tour de boucle.
-- J-L.M. http://www.bribes.org/perl
Dans l'article <43b1b64d$0$23994$626a14ce@news.free.fr>, Rocco@mail.fr a
dit...
sub doZip {
my ($fichier,$fichierreg, $nomZip) = @_ ;
open FICHIER, $fichier ;
my $ligne, my $longueur;
my $zip = Archive::Zip->new();
while (<FICHIER>) {
next if (($longueur=length($_)-2) <= 0);
$ligne = "$_";
my @lig = split /|/,$ligne;
if ($lig[0]=~ m/^+ .+$/ ) {
my $prog = substr($lig[0],2,length($lig[0])-2);
chomp $prog;
print ""$prog"";
warn "Error adding file $prog : $!n" ;#if
($zip->addFile($prog) != AZ_OK);
}
}
unlink($nomZip);
$zip->addFile($fichier,"$install/$fichier") or warn "Error
adding file $fichiern";
$zip->addFile($fichierreg,"$install/$fichierreg")or warn
"Error adding file $fichierregn";
if($zip->writeToFileNamed($nomZip) != AZ_OK){
die 'write error Zip';
}
}
Le but est de parcourir un fichier et de zipper tous les noms de
fichiers contenus a l'intérieur.
Le souci est que chaque fichier lu admet une Bad file descriptor
Que signifie cette erreur ?
Il manque un close FICHIER à la fin de votre boucle.
Vous ne pouvez pas ouvrir un fichier qui est déjà ouvert au premier
tour de boucle.
sub doZip { my ($fichier,$fichierreg, $nomZip) = @_ ; open FICHIER, $fichier ; my $ligne, my $longueur; my $zip = Archive::Zip->new();
while (<FICHIER>) { next if (($longueur=length($_)-2) <= 0); $ligne = "$_"; my @lig = split /|/,$ligne; if ($lig[0]=~ m/^+ .+$/ ) { my $prog = substr($lig[0],2,length($lig[0])-2); chomp $prog; print ""$prog""; warn "Error adding file $prog : $!n" ;#if ($zip->addFile($prog) != AZ_OK); } } unlink($nomZip); $zip->addFile($fichier,"$install/$fichier") or warn "Error adding file $fichiern"; $zip->addFile($fichierreg,"$install/$fichierreg")or warn "Error adding file $fichierregn"; if($zip->writeToFileNamed($nomZip) != AZ_OK){ die 'write error Zip'; } }
Le but est de parcourir un fichier et de zipper tous les noms de fichiers contenus a l'intérieur. Le souci est que chaque fichier lu admet une Bad file descriptor Que signifie cette erreur ?
Il manque un close FICHIER à la fin de votre boucle. Vous ne pouvez pas ouvrir un fichier qui est déjà ouvert au premier tour de boucle.
-- J-L.M. http://www.bribes.org/perl
Nicolas George
Jean-Louis MOREL wrote in message <43b24406$0$7381$:
Vous ne pouvez pas ouvrir un fichier qui est déjà ouvert au premier tour de boucle.
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc, mais normalement, réutiliser un filehandle déjà ouvert pour ouvrir un nouveau fichier ferme automatiquement le précédent fichier.
(Et si on utilise l'autovivification des scalaires lexicaux, c'est encore plus clair : la variable sort de visibilité, le fichier est fermé.)
Jean-Louis MOREL wrote in message
<43b24406$0$7381$636a55ce@news.free.fr>:
Vous ne pouvez pas ouvrir un fichier qui est déjà ouvert au premier
tour de boucle.
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc, mais
normalement, réutiliser un filehandle déjà ouvert pour ouvrir un nouveau
fichier ferme automatiquement le précédent fichier.
(Et si on utilise l'autovivification des scalaires lexicaux, c'est encore
plus clair : la variable sort de visibilité, le fichier est fermé.)
Jean-Louis MOREL wrote in message <43b24406$0$7381$:
Vous ne pouvez pas ouvrir un fichier qui est déjà ouvert au premier tour de boucle.
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc, mais normalement, réutiliser un filehandle déjà ouvert pour ouvrir un nouveau fichier ferme automatiquement le précédent fichier.
(Et si on utilise l'autovivification des scalaires lexicaux, c'est encore plus clair : la variable sort de visibilité, le fichier est fermé.)
jl_morel
Dans l'article <dou0po$18qo$, nicolas$ a dit...
Jean-Louis MOREL wrote in message <43b24406$0$7381$:
Vous ne pouvez pas ouvrir un fichier qui est déjà ouvert au premier tour de boucle.
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc, mais normalement, réutiliser un filehandle déjà ouvert pour ouvrir un nouveau fichier ferme automatiquement le précédent fichier.
Ça dépend du système. Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert. Naturellement, avec des OS moins stricts que Windows on peut certainement le faire; la permissivité de certains systèmes n'a pas de borne; quelle honte d'encourager la mauvaise programmation ! (bon, là c'était mon petit troll de fin d'année pour mettre un peu d'ambiance ;-))
(Et si on utilise l'autovivification des scalaires lexicaux, c'est encore plus clair : la variable sort de visibilité, le fichier est fermé.)
Tout à fait. C'est ce que recommande Damian Conway dans Perl Best Practices. Il aurait fallu écrire open my $FICHIER, '<', $fichier or die $!;
En fin de routine le fichier est automatiquement fermé car la portée de $FICHIER est limité à cette routine. Il est recommandé néanmoins de fermer explicitement les filehandles, et aussitôt que possible (on économise souvent des ressources).
-- J-L.M. http://www.bribes.org/perl
Dans l'article <dou0po$18qo$1@biggoron.nerim.net>, nicolas$george@salle-s.org a
dit...
Jean-Louis MOREL wrote in message
<43b24406$0$7381$636a55ce@news.free.fr>:
Vous ne pouvez pas ouvrir un fichier qui est déjà ouvert au premier
tour de boucle.
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc, mais
normalement, réutiliser un filehandle déjà ouvert pour ouvrir un nouveau
fichier ferme automatiquement le précédent fichier.
Ça dépend du système. Sous Windows, je suis formel, on ne peut pas ouvrir
un fichier déjà ouvert. Naturellement, avec des OS moins stricts que
Windows on peut certainement le faire; la permissivité de certains systèmes
n'a pas de borne; quelle honte d'encourager la mauvaise programmation !
(bon, là c'était mon petit troll de fin d'année pour mettre un peu
d'ambiance ;-))
(Et si on utilise l'autovivification des scalaires lexicaux, c'est encore
plus clair : la variable sort de visibilité, le fichier est fermé.)
Tout à fait. C'est ce que recommande Damian Conway dans Perl Best
Practices.
Il aurait fallu écrire
open my $FICHIER, '<', $fichier or die $!;
En fin de routine le fichier est automatiquement fermé car la portée de
$FICHIER est limité à cette routine.
Il est recommandé néanmoins de fermer explicitement les filehandles, et
aussitôt que possible (on économise souvent des ressources).
Jean-Louis MOREL wrote in message <43b24406$0$7381$:
Vous ne pouvez pas ouvrir un fichier qui est déjà ouvert au premier tour de boucle.
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc, mais normalement, réutiliser un filehandle déjà ouvert pour ouvrir un nouveau fichier ferme automatiquement le précédent fichier.
Ça dépend du système. Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert. Naturellement, avec des OS moins stricts que Windows on peut certainement le faire; la permissivité de certains systèmes n'a pas de borne; quelle honte d'encourager la mauvaise programmation ! (bon, là c'était mon petit troll de fin d'année pour mettre un peu d'ambiance ;-))
(Et si on utilise l'autovivification des scalaires lexicaux, c'est encore plus clair : la variable sort de visibilité, le fichier est fermé.)
Tout à fait. C'est ce que recommande Damian Conway dans Perl Best Practices. Il aurait fallu écrire open my $FICHIER, '<', $fichier or die $!;
En fin de routine le fichier est automatiquement fermé car la portée de $FICHIER est limité à cette routine. Il est recommandé néanmoins de fermer explicitement les filehandles, et aussitôt que possible (on économise souvent des ressources).
-- J-L.M. http://www.bribes.org/perl
Vincent Lefevre
Dans l'article <43b2a9ed$0$7382$, Jean-Louis MOREL écrit:
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc, mais normalement, réutiliser un filehandle déjà ouvert pour ouvrir un nouveau fichier ferme automatiquement le précédent fichier.
Ça dépend du système. Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert.
Ça ne devrait pas dépendre du système, ou alors c'est un bug dans l'implémentation. C'est explicitement décrit sous la fonction close (qui est une fonction de Perl, pas une fonction du système):
You don't have to close FILEHANDLE if you are immediately going to do another "open" on it, because "open" will close it for you. (See "open".) However, an explicit "close" on an input file resets the line counter ($.), while the implicit close done by "open" does not.
(En fait, il y a certains cas où ça ne fonctionne pas, cf "open".)
Dans l'article <43b2a9ed$0$7382$636a55ce@news.free.fr>,
Jean-Louis MOREL <jl_morel@bribes.org> écrit:
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc,
mais normalement, réutiliser un filehandle déjà ouvert pour ouvrir
un nouveau fichier ferme automatiquement le précédent fichier.
Ça dépend du système. Sous Windows, je suis formel, on ne peut pas
ouvrir un fichier déjà ouvert.
Ça ne devrait pas dépendre du système, ou alors c'est un bug dans
l'implémentation. C'est explicitement décrit sous la fonction close
(qui est une fonction de Perl, pas une fonction du système):
You don't have to close FILEHANDLE if you are immediately going
to do another "open" on it, because "open" will close it for
you. (See "open".) However, an explicit "close" on an input
file resets the line counter ($.), while the implicit close
done by "open" does not.
(En fait, il y a certains cas où ça ne fonctionne pas, cf "open".)
Dans l'article <43b2a9ed$0$7382$, Jean-Louis MOREL écrit:
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc, mais normalement, réutiliser un filehandle déjà ouvert pour ouvrir un nouveau fichier ferme automatiquement le précédent fichier.
Ça dépend du système. Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert.
Ça ne devrait pas dépendre du système, ou alors c'est un bug dans l'implémentation. C'est explicitement décrit sous la fonction close (qui est une fonction de Perl, pas une fonction du système):
You don't have to close FILEHANDLE if you are immediately going to do another "open" on it, because "open" will close it for you. (See "open".) However, an explicit "close" on an input file resets the line counter ($.), while the implicit close done by "open" does not.
(En fait, il y a certains cas où ça ne fonctionne pas, cf "open".)
Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert. Naturellement, avec des OS moins stricts que Windows
Tu es en train de confondre "strict" et "inutilement emmerdant".
L'ouverture d'un fichier constitue une opération longue, peu fréquente, et en conséquence la vérification au moment de l'ouverture que le decripteur n'est pas déjà utilisé ne coûte pour ainsi dire *rien* .
Le temps de programmeur (surtout en maintenance) coûte, lui, quelque chose. Moins il y a de lignes à maintenir, qui gênent la lisibilité du reste, et mieux cela vaut. L'idéal (rarement atteint, mais Perl n'est pas trop mauvais dans le domaine) serait "une idée, une instruction".
Les prenthésages, qui sont une aide au début, deviennent une plaie avec la complexité croissante des programmes. C'est d'ailleurs pour cela que Python, en dépit de ses défauts, vole chaque mois des adeptes à Perl.
Sous Windows, je suis formel, on ne peut pas ouvrir
un fichier déjà ouvert. Naturellement, avec des OS moins stricts que
Windows
Tu es en train de confondre "strict" et "inutilement emmerdant".
L'ouverture d'un fichier constitue une opération longue, peu fréquente,
et en conséquence la vérification au moment de l'ouverture que le
decripteur n'est pas déjà utilisé ne coûte pour ainsi dire *rien* .
Le temps de programmeur (surtout en maintenance) coûte, lui, quelque
chose. Moins il y a de lignes à maintenir, qui gênent la lisibilité du
reste, et mieux cela vaut. L'idéal (rarement atteint, mais Perl n'est
pas trop mauvais dans le domaine) serait "une idée, une instruction".
Les prenthésages, qui sont une aide au début, deviennent une plaie avec
la complexité croissante des programmes. C'est d'ailleurs pour cela que
Python, en dépit de ses défauts, vole chaque mois des adeptes à Perl.
Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert. Naturellement, avec des OS moins stricts que Windows
Tu es en train de confondre "strict" et "inutilement emmerdant".
L'ouverture d'un fichier constitue une opération longue, peu fréquente, et en conséquence la vérification au moment de l'ouverture que le decripteur n'est pas déjà utilisé ne coûte pour ainsi dire *rien* .
Le temps de programmeur (surtout en maintenance) coûte, lui, quelque chose. Moins il y a de lignes à maintenir, qui gênent la lisibilité du reste, et mieux cela vaut. L'idéal (rarement atteint, mais Perl n'est pas trop mauvais dans le domaine) serait "une idée, une instruction".
Les prenthésages, qui sont une aide au début, deviennent une plaie avec la complexité croissante des programmes. C'est d'ailleurs pour cela que Python, en dépit de ses défauts, vole chaque mois des adeptes à Perl.
FDA
Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert. Naturellement, avec des OS moins stricts que Windows
Tu es en train de confondre "strict" et "inutilement emmerdant".
L'ouverture d'un fichier constitue une opération longue, peu fréquente, et en conséquence la vérification au moment de l'ouverture que le decripteur n'est pas déjà utilisé ne coûte pour ainsi dire *rien* .
Le temps de programmeur (surtout en maintenance) coûte, lui, quelque chose. Moins il y a de lignes à maintenir, qui gênent la lisibilité du reste, et mieux cela vaut. L'idéal (rarement atteint, mais Perl n'est pas trop mauvais dans le domaine) serait "une idée, une instruction".
Les prenthésages, qui sont une aide au début, deviennent une plaie avec la complexité croissante des programmes. C'est d'ailleurs pour cela que Python, en dépit de ses défauts, vole chaque mois des adeptes à Perl (mais c'est aussi parce que ça me faisait économiser des parenthèses, donc que je lisais mieux mes programmes, que je suis passé du C à Perl, en acceptant de bonne grâce la perte de performance - légère dans mon cas, car mes programmes sont plutôt limités en performances par les E/S disque).
Sous Windows, je suis formel, on ne peut pas ouvrir
un fichier déjà ouvert. Naturellement, avec des OS moins stricts que
Windows
Tu es en train de confondre "strict" et "inutilement emmerdant".
L'ouverture d'un fichier constitue une opération longue, peu fréquente,
et en conséquence la vérification au moment de l'ouverture que le
decripteur n'est pas déjà utilisé ne coûte pour ainsi dire *rien* .
Le temps de programmeur (surtout en maintenance) coûte, lui, quelque
chose. Moins il y a de lignes à maintenir, qui gênent la lisibilité du
reste, et mieux cela vaut. L'idéal (rarement atteint, mais Perl n'est
pas trop mauvais dans le domaine) serait "une idée, une instruction".
Les prenthésages, qui sont une aide au début, deviennent une plaie avec
la complexité croissante des programmes. C'est d'ailleurs pour cela que
Python, en dépit de ses défauts, vole chaque mois des adeptes à Perl
(mais c'est aussi parce que ça me faisait économiser des parenthèses,
donc que je lisais mieux mes programmes, que je suis passé du C à Perl,
en acceptant de bonne grâce la perte de performance - légère dans mon
cas, car mes programmes sont plutôt limités en performances par les E/S
disque).
Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert. Naturellement, avec des OS moins stricts que Windows
Tu es en train de confondre "strict" et "inutilement emmerdant".
L'ouverture d'un fichier constitue une opération longue, peu fréquente, et en conséquence la vérification au moment de l'ouverture que le decripteur n'est pas déjà utilisé ne coûte pour ainsi dire *rien* .
Le temps de programmeur (surtout en maintenance) coûte, lui, quelque chose. Moins il y a de lignes à maintenir, qui gênent la lisibilité du reste, et mieux cela vaut. L'idéal (rarement atteint, mais Perl n'est pas trop mauvais dans le domaine) serait "une idée, une instruction".
Les prenthésages, qui sont une aide au début, deviennent une plaie avec la complexité croissante des programmes. C'est d'ailleurs pour cela que Python, en dépit de ses défauts, vole chaque mois des adeptes à Perl (mais c'est aussi parce que ça me faisait économiser des parenthèses, donc que je lisais mieux mes programmes, que je suis passé du C à Perl, en acceptant de bonne grâce la perte de performance - légère dans mon cas, car mes programmes sont plutôt limités en performances par les E/S disque).
jl_morel
Dans l'article <20051228195825$, vincent+ a dit...
Dans l'article <43b2a9ed$0$7382$, Jean-Louis MOREL écrit:
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc, mais normalement, réutiliser un filehandle déjà ouvert pour ouvrir un nouveau fichier ferme automatiquement le précédent fichier.
Ça dépend du système. Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert.
Ça ne devrait pas dépendre du système, ou alors c'est un bug dans l'implémentation. C'est explicitement décrit sous la fonction close (qui est une fonction de Perl, pas une fonction du système):
You don't have to close FILEHANDLE if you are immediately going to do another "open" on it, because "open" will close it for you. (See "open".) However, an explicit "close" on an input file resets the line counter ($.), while the implicit close done by "open" does not.
(En fait, il y a certains cas où ça ne fonctionne pas, cf "open".)
Au temps pour moi; j'ai dit une bêtise; vous avez raison tous les deux : le filehandle est bien fermé si on l'ouvre à nouveau. (J'ai fait une confusion à partir des résultats obtenus il y a quelque temps avec un script, mais j'utilisais le module WIN32API::File et c'est une autre histoire)
Alors, on peut mal programmer même sous Windows ! Ah ! Je suis déçu ! ;-)
-- J-L.M. http://www.bribes.org/perl
Dans l'article <20051228195825$46db@ay.vinc17.org>, vincent+news@vinc17.org a
dit...
Dans l'article <43b2a9ed$0$7382$636a55ce@news.free.fr>,
Jean-Louis MOREL <jl_morel@bribes.org> écrit:
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc,
mais normalement, réutiliser un filehandle déjà ouvert pour ouvrir
un nouveau fichier ferme automatiquement le précédent fichier.
Ça dépend du système. Sous Windows, je suis formel, on ne peut pas
ouvrir un fichier déjà ouvert.
Ça ne devrait pas dépendre du système, ou alors c'est un bug dans
l'implémentation. C'est explicitement décrit sous la fonction close
(qui est une fonction de Perl, pas une fonction du système):
You don't have to close FILEHANDLE if you are immediately going
to do another "open" on it, because "open" will close it for
you. (See "open".) However, an explicit "close" on an input
file resets the line counter ($.), while the implicit close
done by "open" does not.
(En fait, il y a certains cas où ça ne fonctionne pas, cf "open".)
Au temps pour moi; j'ai dit une bêtise; vous avez raison tous les deux : le
filehandle est bien fermé si on l'ouvre à nouveau.
(J'ai fait une confusion à partir des résultats obtenus il y a quelque
temps avec un script, mais j'utilisais le module WIN32API::File et c'est
une autre histoire)
Alors, on peut mal programmer même sous Windows !
Ah ! Je suis déçu ! ;-)
Dans l'article <20051228195825$, vincent+ a dit...
Dans l'article <43b2a9ed$0$7382$, Jean-Louis MOREL écrit:
Euh, si. Je n'arrive pas à retrouver où c'est énoncé dans la doc, mais normalement, réutiliser un filehandle déjà ouvert pour ouvrir un nouveau fichier ferme automatiquement le précédent fichier.
Ça dépend du système. Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert.
Ça ne devrait pas dépendre du système, ou alors c'est un bug dans l'implémentation. C'est explicitement décrit sous la fonction close (qui est une fonction de Perl, pas une fonction du système):
You don't have to close FILEHANDLE if you are immediately going to do another "open" on it, because "open" will close it for you. (See "open".) However, an explicit "close" on an input file resets the line counter ($.), while the implicit close done by "open" does not.
(En fait, il y a certains cas où ça ne fonctionne pas, cf "open".)
Au temps pour moi; j'ai dit une bêtise; vous avez raison tous les deux : le filehandle est bien fermé si on l'ouvre à nouveau. (J'ai fait une confusion à partir des résultats obtenus il y a quelque temps avec un script, mais j'utilisais le module WIN32API::File et c'est une autre histoire)
Alors, on peut mal programmer même sous Windows ! Ah ! Je suis déçu ! ;-)
-- J-L.M. http://www.bribes.org/perl
jl_morel
Dans l'article <43b42567$0$30593$, a dit...
Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert. Naturellement, avec des OS moins stricts que Windows
Tu es en train de confondre "strict" et "inutilement emmerdant".
L'ouverture d'un fichier constitue une opération longue, peu fréquente, et en conséquence la vérification au moment de l'ouverture que le decripteur n'est pas déjà utilisé ne coûte pour ainsi dire *rien* .
Le temps de programmeur (surtout en maintenance) coûte, lui, quelque chose. Moins il y a de lignes à maintenir, qui gênent la lisibilité du reste, et mieux cela vaut. L'idéal (rarement atteint, mais Perl n'est pas trop mauvais dans le domaine) serait "une idée, une instruction".
Les prenthésages, qui sont une aide au début, deviennent une plaie avec la complexité croissante des programmes. C'est d'ailleurs pour cela que Python, en dépit de ses défauts, vole chaque mois des adeptes à Perl (mais c'est aussi parce que ça me faisait économiser des parenthèses, donc que je lisais mieux mes programmes, que je suis passé du C à Perl, en acceptant de bonne grâce la perte de performance - légère dans mon cas, car mes programmes sont plutôt limités en performances par les E/S disque).
Il faut noter que ma remarque était ironique. (il marche pas mal mon petit troll finalement :-)
Le fait que la fonction open ferme un descripteur déjà utilisé avant de le rouvrir peut être intéressant dans un oneliner. Dans un script de quelques dizaines de lignes aussi. Mais dans un gros programme ça peut entraîner des effets de bord difficiles à localiser (le descripteur est global). Dans ce cas, je crois qu'il est préférable de mettre systématiquement un close après chaque open, même si ça fait une ligne de plus (est-ce que ça diminue la lisibilité ?).
Le langage informatique idéal n'existe pas; il faut positiver : la programmation serait une bien triste activité s'il n'y avait pas une chasse aux bugs de temps en temps ;-)
-- J-L.M. http://www.bribes.org/perl
Dans l'article <43b42567$0$30593$79c14f64@nan-newsreader-06.noos.net>,
armingaud@gmail.com a dit...
Sous Windows, je suis formel, on ne peut pas ouvrir
un fichier déjà ouvert. Naturellement, avec des OS moins stricts que
Windows
Tu es en train de confondre "strict" et "inutilement emmerdant".
L'ouverture d'un fichier constitue une opération longue, peu fréquente,
et en conséquence la vérification au moment de l'ouverture que le
decripteur n'est pas déjà utilisé ne coûte pour ainsi dire *rien* .
Le temps de programmeur (surtout en maintenance) coûte, lui, quelque
chose. Moins il y a de lignes à maintenir, qui gênent la lisibilité du
reste, et mieux cela vaut. L'idéal (rarement atteint, mais Perl n'est
pas trop mauvais dans le domaine) serait "une idée, une instruction".
Les prenthésages, qui sont une aide au début, deviennent une plaie avec
la complexité croissante des programmes. C'est d'ailleurs pour cela que
Python, en dépit de ses défauts, vole chaque mois des adeptes à Perl
(mais c'est aussi parce que ça me faisait économiser des parenthèses,
donc que je lisais mieux mes programmes, que je suis passé du C à Perl,
en acceptant de bonne grâce la perte de performance - légère dans mon
cas, car mes programmes sont plutôt limités en performances par les E/S
disque).
Il faut noter que ma remarque était ironique.
(il marche pas mal mon petit troll finalement :-)
Le fait que la fonction open ferme un descripteur déjà utilisé avant de le
rouvrir peut être intéressant dans un oneliner. Dans un script de quelques
dizaines de lignes aussi. Mais dans un gros programme ça peut entraîner des
effets de bord difficiles à localiser (le descripteur est global).
Dans ce cas, je crois qu'il est préférable de mettre systématiquement un
close après chaque open, même si ça fait une ligne de plus (est-ce que ça
diminue la lisibilité ?).
Le langage informatique idéal n'existe pas; il faut positiver : la
programmation serait une bien triste activité s'il n'y avait pas une chasse
aux bugs de temps en temps ;-)
Sous Windows, je suis formel, on ne peut pas ouvrir un fichier déjà ouvert. Naturellement, avec des OS moins stricts que Windows
Tu es en train de confondre "strict" et "inutilement emmerdant".
L'ouverture d'un fichier constitue une opération longue, peu fréquente, et en conséquence la vérification au moment de l'ouverture que le decripteur n'est pas déjà utilisé ne coûte pour ainsi dire *rien* .
Le temps de programmeur (surtout en maintenance) coûte, lui, quelque chose. Moins il y a de lignes à maintenir, qui gênent la lisibilité du reste, et mieux cela vaut. L'idéal (rarement atteint, mais Perl n'est pas trop mauvais dans le domaine) serait "une idée, une instruction".
Les prenthésages, qui sont une aide au début, deviennent une plaie avec la complexité croissante des programmes. C'est d'ailleurs pour cela que Python, en dépit de ses défauts, vole chaque mois des adeptes à Perl (mais c'est aussi parce que ça me faisait économiser des parenthèses, donc que je lisais mieux mes programmes, que je suis passé du C à Perl, en acceptant de bonne grâce la perte de performance - légère dans mon cas, car mes programmes sont plutôt limités en performances par les E/S disque).
Il faut noter que ma remarque était ironique. (il marche pas mal mon petit troll finalement :-)
Le fait que la fonction open ferme un descripteur déjà utilisé avant de le rouvrir peut être intéressant dans un oneliner. Dans un script de quelques dizaines de lignes aussi. Mais dans un gros programme ça peut entraîner des effets de bord difficiles à localiser (le descripteur est global). Dans ce cas, je crois qu'il est préférable de mettre systématiquement un close après chaque open, même si ça fait une ligne de plus (est-ce que ça diminue la lisibilité ?).
Le langage informatique idéal n'existe pas; il faut positiver : la programmation serait une bien triste activité s'il n'y avait pas une chasse aux bugs de temps en temps ;-)
-- J-L.M. http://www.bribes.org/perl
Nicolas George
Jean-Louis MOREL wrote in message <43b5266e$0$7956$:
Le fait que la fonction open ferme un descripteur déjà utilisé avant de le rouvrir peut être intéressant dans un oneliner. Dans un script de quelques dizaines de lignes aussi. Mais dans un gros programme ça peut entraîner des effets de bord difficiles à localiser (le descripteur est global). ^^^^^^^^^^^^^^^^^^^^^^^^^
Dans ce cas, je crois qu'il est préférable de mettre systématiquement un close après chaque open, même si ça fait une ligne de plus (est-ce que ça diminue la lisibilité ?).
J'ai souligné le principal problème. Et la solution passe par le fait d'utiliser un descripteur de fichier à portée lexicale autant que possible, et soumis au GC sinon.
Jean-Louis MOREL wrote in message
<43b5266e$0$7956$626a14ce@news.free.fr>:
Le fait que la fonction open ferme un descripteur déjà utilisé avant de le
rouvrir peut être intéressant dans un oneliner. Dans un script de quelques
dizaines de lignes aussi. Mais dans un gros programme ça peut entraîner des
effets de bord difficiles à localiser (le descripteur est global).
^^^^^^^^^^^^^^^^^^^^^^^^^
Dans ce cas, je crois qu'il est préférable de mettre systématiquement un
close après chaque open, même si ça fait une ligne de plus (est-ce que ça
diminue la lisibilité ?).
J'ai souligné le principal problème. Et la solution passe par le fait
d'utiliser un descripteur de fichier à portée lexicale autant que possible,
et soumis au GC sinon.
Jean-Louis MOREL wrote in message <43b5266e$0$7956$:
Le fait que la fonction open ferme un descripteur déjà utilisé avant de le rouvrir peut être intéressant dans un oneliner. Dans un script de quelques dizaines de lignes aussi. Mais dans un gros programme ça peut entraîner des effets de bord difficiles à localiser (le descripteur est global). ^^^^^^^^^^^^^^^^^^^^^^^^^
Dans ce cas, je crois qu'il est préférable de mettre systématiquement un close après chaque open, même si ça fait une ligne de plus (est-ce que ça diminue la lisibilité ?).
J'ai souligné le principal problème. Et la solution passe par le fait d'utiliser un descripteur de fichier à portée lexicale autant que possible, et soumis au GC sinon.
FDA
Dans ce cas, je crois qu'il est préférable de mettre systématiquement un close après chaque open, même si ça fait une ligne de plus (est-ce que ça diminue la lisibilité ?).
Eh bien si tu vas au CeBIT chaque année, tu t'es certainement demandé aussi : "Est-ce que prencre ce petit prospectus intéressant me chargea beaucoup ?", et la réponse est évidemment "non". Moyennant quoi... tu quittes le CeBIT à 15h30 alors qu'il y a encore tant de choses passionnantes à voir, parce que tu n'en peux plus de porter tes N kilos de prospectus ramassés à droite et à gauche :-D
Une ligne de plus (sur le papier), c'est une ligne en moins (dans son scope personnel), pour reprendre une idée de J.F. Batellier.
(Au fait, "side effects", j'ai toujours traduit cela par "effets secondaires - ce qu'ils sont en réalité - et n'ai jamais compris pourquo Paris VI traduisait ça par "effet de bord"; à mon avis, parce qu'ils maîtrisent l'anglais à peu près aussi bien que moi le russe :-( )
Le langage informatique idéal n'existe pas; il faut positiver : la programmation serait une bien triste activité s'il n'y avait pas une chasse aux bugs de temps en temps ;-)
Juste ! En plus, cela préserve l'emploi :-)
Mais j'ai connu un chercheur en physique, à Munich, qui me disait connaître le langage de programmation idéal : cela consistait pour lui à gribouiller trois ou quatre équations différentielles avec des conditions aux limites sur un bout de papier, et à demander un programmeur du centre : "peux-tu me programmer ça pour midi ?" ;-)
Onéreux, mais efficace. Avec les restrictions de crédits, je suppose qu'il est passé à Maple ou Mathematica, comme tout le monde :-)
Dans ce cas, je crois qu'il est préférable de mettre systématiquement un
close après chaque open, même si ça fait une ligne de plus (est-ce que ça
diminue la lisibilité ?).
Eh bien si tu vas au CeBIT chaque année, tu t'es certainement demandé
aussi : "Est-ce que prencre ce petit prospectus intéressant me chargea
beaucoup ?", et la réponse est évidemment "non". Moyennant quoi... tu
quittes le CeBIT à 15h30 alors qu'il y a encore tant de choses
passionnantes à voir, parce que tu n'en peux plus de porter tes N kilos
de prospectus ramassés à droite et à gauche :-D
Une ligne de plus (sur le papier), c'est une ligne en moins (dans son
scope personnel), pour reprendre une idée de J.F. Batellier.
(Au fait, "side effects", j'ai toujours traduit cela par "effets
secondaires - ce qu'ils sont en réalité - et n'ai jamais compris pourquo
Paris VI traduisait ça par "effet de bord"; à mon avis, parce qu'ils
maîtrisent l'anglais à peu près aussi bien que moi le russe :-( )
Le langage informatique idéal n'existe pas; il faut positiver : la
programmation serait une bien triste activité s'il n'y avait pas une chasse
aux bugs de temps en temps ;-)
Juste ! En plus, cela préserve l'emploi :-)
Mais j'ai connu un chercheur en physique, à Munich, qui me disait
connaître le langage de programmation idéal : cela consistait pour lui à
gribouiller trois ou quatre équations différentielles avec des
conditions aux limites sur un bout de papier, et à demander un
programmeur du centre : "peux-tu me programmer ça pour midi ?" ;-)
Onéreux, mais efficace. Avec les restrictions de crédits, je suppose
qu'il est passé à Maple ou Mathematica, comme tout le monde :-)
Dans ce cas, je crois qu'il est préférable de mettre systématiquement un close après chaque open, même si ça fait une ligne de plus (est-ce que ça diminue la lisibilité ?).
Eh bien si tu vas au CeBIT chaque année, tu t'es certainement demandé aussi : "Est-ce que prencre ce petit prospectus intéressant me chargea beaucoup ?", et la réponse est évidemment "non". Moyennant quoi... tu quittes le CeBIT à 15h30 alors qu'il y a encore tant de choses passionnantes à voir, parce que tu n'en peux plus de porter tes N kilos de prospectus ramassés à droite et à gauche :-D
Une ligne de plus (sur le papier), c'est une ligne en moins (dans son scope personnel), pour reprendre une idée de J.F. Batellier.
(Au fait, "side effects", j'ai toujours traduit cela par "effets secondaires - ce qu'ils sont en réalité - et n'ai jamais compris pourquo Paris VI traduisait ça par "effet de bord"; à mon avis, parce qu'ils maîtrisent l'anglais à peu près aussi bien que moi le russe :-( )
Le langage informatique idéal n'existe pas; il faut positiver : la programmation serait une bien triste activité s'il n'y avait pas une chasse aux bugs de temps en temps ;-)
Juste ! En plus, cela préserve l'emploi :-)
Mais j'ai connu un chercheur en physique, à Munich, qui me disait connaître le langage de programmation idéal : cela consistait pour lui à gribouiller trois ou quatre équations différentielles avec des conditions aux limites sur un bout de papier, et à demander un programmeur du centre : "peux-tu me programmer ça pour midi ?" ;-)
Onéreux, mais efficace. Avec les restrictions de crédits, je suppose qu'il est passé à Maple ou Mathematica, comme tout le monde :-)
