Combien de programmeurs ont un point de vue informé sur la question ? Combien ont eu la curiosité et/ou l'occasion de sortir des sentiers battus et d'utiliser un langage fonctionnel ou logique pour un projet conséquent (i.e. plus grand qu'un TP) ?
Dans mon entourage professionnel : 0.
Alors malgré tout le respect que j'ai pour eux, leur avis sur la question me semble assez peu pertinent.
Ben même si tu te cantonnes à un style de programmation, tu disposes toujours du polymorphisme "for free", du typage statique, implicite et fort, des fonctions comme citoyens de 1ère classe du langage, du garbage collector, de la possiblité de générer du bytecode portable ou du code natif optimisé rapide, du système très puissant de modules, de l'héritage multiple, des closures, de la méta-programmation (avec MetaOcaml), d'un pré-processeur-pretty-printer très paramétrable, d'un support pour l'évaluation paresseuse, etc... qui sont d'autres caractéristiques (je ne dis pas "qualités") qui peuvent intervenir dans ton choix de langage.
En ce qui me concerne, ce sont d'ailleurs généralement certaines d'entre elles qui me font opter pour OCaml. Et l'aspect multi-paradigme d'Ocaml me permet de tirer avantage de toutes ces caractéristiques sans être contraint à un style de programmation particulier.
Pour préciser ce que je voulais dire sur le mélange des styles:
la dernière fois que j'ai utilisé ce langage, c'était pour un problème pour lequel un algo impérativo-fonctionnel (ie un algo récursif avec des applications partielles, ainsi qu'un environnement qui varie au cours de l'algo) était beaucoup plus simple et rapide qu'une solution purement impérative (qui simule la récursivité avec une pile) ou purement fonctionnelle (où la gestion d'un environnement non modifiable compliquait l'algorithme). OCaml m'a permis d'exprimer cette fonction à style mélangé de manière très naturelle et efficace à l'exécution.
Par contre d'autres langages comme OCaml ou pire Prolog sont beaucoup plus difficile à appréhender car il demande une réflexion importante de la part du programmeur pour qu'il "ponde" le bon algo de manière conscise, sans parfois avoir la possibilité de décomposer le problème.
C'est une idée fausse hélas très répandue sur OCaml. OCaml est un langage multiparadigme, qui permet de travailler aussi facilement de manière fonctionnelle, impérative ou objets. Une des ses principales qualités est en effet justement de permettre au programmeur d'alterner et mélanger facilement ces trois styles de programmation en fonction des caractéristiques du problème qu'il traite.
Mais dans l'enseignement, les différents dialectes de ML sont utilisés essentiellement (voire exclusivement, comme dans mon ancienne fac) pour familiariser l'étudiant avec le style de programmation fonctionnelle, d'où cette fausse image du langage.
J'ai utilisé des DVD-R Bulkpaq. Après avoir grillé une dizaine de DVD, j'ai eu la présence d'esprit d'utiliser -dummy pour les essais suivants.
J'ai réussi a utiliser dvdrecord -scanbus (il suffisait de rajouter -dev=ATAPI ou quelque chose à cet effet). La gravure avec dvdrecord n'a pas marché, toujours le même problème de vitesse. Je n'ai pas essayé cdrecord-prodvd.
J'ai regardé en diagonale la spécification MM5, la dernière version des commandes SCSI pour le multimedia. Apparemment, la taille d'un bloc d'écriture pour les DVD est de 2k. 32k correspond à la taille d'un bloc ECC (Error-Correcting quelqueChose ?). Je n'ai rien trouvé qui impose d'avoir des blocs par groupe de 16 (32/2) lors d'une commande WRITE.
Ce commentaire est un peu prématuré, vu qu'il y a encore un paquet de choses que je ne comprends ou ne sais pas dans MM5 et growisofs. C'est juste pour signaler que j'ai pas lâché l'affaire.
J'ai essayé de mon côté avec pipebuf2 :
mkisofs -r -J movies/ | pipebuf2 -b 32 -i 1 | growisofs -dvd-compat -speed=1 -use-the-force-luke=dummy -use-the-force-luke=dao -Z /dev/hdc=/dev/fd/0
Le buffer de pipebuf2 était toujours plein, mais la LED clignotait toujours aussi vite. Idem avec -b 64. Après j'ai essayé de faire mkisofs à l'avance.
Même résultat. Après je me suis plongé dans le code de growisofs. J'ai commencé à rajouter un buffer. Au bout d'un moment, j'ai eu l'idée d'une expérience: j'ai remplacé la boucle d'écriture principale
while ((n=read (infd,the_buffer+off,DVD_BLOCK-off)) > 0)
par
while (1)
ce qui fait que le programme ne lit jamais de données en entrée, et grave le même bloc de 32k encore et encore. Cela m'a permis de tester si c'était la lecture de l'iso par le pipe qui ralentissait le reste.
Hélas, le résultat était toujours aussi mauvais. Ce n'est donc pas un problème de buffer. La seule possibilité que je vois encore pour s'en sortir avec growisofs consisterait à tenter d'optimiser la fonction qui se charge de l'écriture (pwrite64_method). Celle-ci ne travaille qu'avec des blocs de 32k. Est-ce un choix de l'auteur ou une contrainte technique ? Dans le premier cas, il y a peut-être moyen d'augmenter cette taille, en espérant que cela améliore les performances. A creuser, mais sans trop d'espoir...
Pour ce qui est du patch dvd, il est aussi présent dans Debian, sous la forme d'un cdrtools patché, modifié et repackagé sous le nom de dvdrtools. La commande s'appelle dvdrecord ici au lieu de cdrecord-dvd.
Je n'arrive pas du tout à la faire marcher chez moi. Même un -scanbus échoue et retourne:
dvdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open SCSI driver.
Le 1er grand pas a été de réussir à envoyer un message avec telnet.
J'ai pu ainsi m'apercevoir que je pouvais mettre à peu près n'importe quoi comme nom de site après le ehlo, mais que le domaine de l'adresse de l'expéditeur devait être un domaine existant.
Le plus important est que cela prouvait qu'il n'y avait pas d'authentification ! Et donc pas besoin de me prendre la tête avec TLS !
Par élimination, le problème venait probablement effectivement du fait que exim4 faisait un "ehlo localdomain.localhost" au lieu d'un "ehlo mamachine". J'ai trituré la config avec dpkg-reconfigure exim4-config, sans succès.
Alors je n'ai plus eu le choix. J'ai du faire ce que je redoutais depuis le début... me plonger dans la spécification Exim, un bien bel ouvrage de 50 chapitres.
Et j'ai trouvé !
Il suffit de rajouter la ligne en gras dans le fichier /etc/exim4/exim4.conf.template (à peu près à la ligne 1250 chez moi).
J'avoue, j'ai eu la flemme de chercher quelle variable contient le nom de ma machine.
Je sais pas si c'est la manière standard de gérer le problème (j'en doute), mais en tout cas ça marche.
Au bout du compte, j'aimerais quand même comprendre pourquoi ce ehlo est rejeté lors d'un connexion par exim4 alors qu'il est valide par telnet...
$ telnet smtp.cegetel.net 25
Trying 212.94.174.24...
Connected to smtp.sitadelle.com.
Escape character is '^]'.
220 smtp.cegetel.net ESMTP Postfix (Debian/GNU)
ehlo mon.adr.esse.ip
250-smtp.cegetel.net
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250 8BITMIME
mail from:xxxxxxx@cegetel.net
250 Ok
rcpt to:xxxxxxxx@cegetel.net
554 <mon.adr.esse.ip>: Helo command rejected: Invalid name
J'ai été surpris de constater qu'il n'y avait pas de ligne 250-AUTH .
Mon nom de machine est arbitraire, je ne suis pas (encore) déclaré sur les serveurs DNS. Est-ce que ça peut jouer ?
Ca n'a probablement rien à voir, mais je ne comprends pas:
$ telnet mon.adr.esse.ip 25
Trying mon.adr.esse.ip...
telnet: Unable to connect to remote host: Connection refused
alors que mon firewall (guarddog) est configuré pour accepter le protocole smtp !?
Oui je sais (c'est même indiqué dans les commentaires du fichier de configuration de mon message intial). Mais le problème est avant tout que je ne connais pas bien les MTA, donc je ne suis pas sûr du tout d'avoir configuré avec les bonnes valeurs. Le fichier .conf.conf que j'ai donné contient la liste des valeurs que j'ai donné lors du dernier dpkg-reconfigure exim4-config. En postant ici, j'espérais que quelqu'un qui est aussi chez cegetel pourrait faire un vdiff rapide avec son propre .conf.conf et me communiquer les différences importantes.
[^] # Re: bof
Posté par remyremy . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 9.
Dans mon entourage professionnel : 0.
Alors malgré tout le respect que j'ai pour eux, leur avis sur la question me semble assez peu pertinent.
[^] # Re: Même problème
Posté par remyremy . En réponse au message problème mplayer-fonts. Évalué à 1.
Merci beaucoup, ça marche aussi chez moi.
[^] # Re: OCaml, oui mais...
Posté par remyremy . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 6.
En ce qui me concerne, ce sont d'ailleurs généralement certaines d'entre elles qui me font opter pour OCaml. Et l'aspect multi-paradigme d'Ocaml me permet de tirer avantage de toutes ces caractéristiques sans être contraint à un style de programmation particulier.
Pour préciser ce que je voulais dire sur le mélange des styles:
la dernière fois que j'ai utilisé ce langage, c'était pour un problème pour lequel un algo impérativo-fonctionnel (ie un algo récursif avec des applications partielles, ainsi qu'un environnement qui varie au cours de l'algo) était beaucoup plus simple et rapide qu'une solution purement impérative (qui simule la récursivité avec une pile) ou purement fonctionnelle (où la gestion d'un environnement non modifiable compliquait l'algorithme). OCaml m'a permis d'exprimer cette fonction à style mélangé de manière très naturelle et efficace à l'exécution.
[^] # Re: OCaml, oui mais...
Posté par remyremy . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 3.
C'est une idée fausse hélas très répandue sur OCaml. OCaml est un langage multiparadigme, qui permet de travailler aussi facilement de manière fonctionnelle, impérative ou objets. Une des ses principales qualités est en effet justement de permettre au programmeur d'alterner et mélanger facilement ces trois styles de programmation en fonction des caractéristiques du problème qu'il traite.
Mais dans l'enseignement, les différents dialectes de ML sont utilisés essentiellement (voire exclusivement, comme dans mon ancienne fac) pour familiariser l'étudiant avec le style de programmation fonctionnelle, d'où cette fausse image du langage.
[^] # Re: Quel programme
Posté par remyremy . En réponse au message problème avec graveur dvd lite-on sohw 812s. Évalué à 1.
J'ai réussi a utiliser dvdrecord -scanbus (il suffisait de rajouter -dev=ATAPI ou quelque chose à cet effet). La gravure avec dvdrecord n'a pas marché, toujours le même problème de vitesse. Je n'ai pas essayé cdrecord-prodvd.
J'ai regardé en diagonale la spécification MM5, la dernière version des commandes SCSI pour le multimedia. Apparemment, la taille d'un bloc d'écriture pour les DVD est de 2k. 32k correspond à la taille d'un bloc ECC (Error-Correcting quelqueChose ?). Je n'ai rien trouvé qui impose d'avoir des blocs par groupe de 16 (32/2) lors d'une commande WRITE.
Ce commentaire est un peu prématuré, vu qu'il y a encore un paquet de choses que je ne comprends ou ne sais pas dans MM5 et growisofs. C'est juste pour signaler que j'ai pas lâché l'affaire.
[^] # Re: Quel programme
Posté par remyremy . En réponse au message problème avec graveur dvd lite-on sohw 812s. Évalué à 1.
mkisofs -r -J movies/ | pipebuf2 -b 32 -i 1 | growisofs -dvd-compat -speed=1 -use-the-force-luke=dummy -use-the-force-luke=dao -Z /dev/hdc=/dev/fd/0
Le buffer de pipebuf2 était toujours plein, mais la LED clignotait toujours aussi vite. Idem avec -b 64. Après j'ai essayé de faire mkisofs à l'avance.
cat movies.iso | pipebuf2 -b 32 -i 1 | growisofs -dvd-compat -speed=1 -use-the-force-luke=dummy -use-the-force-luke=dao -Z /dev/hdc
et
growisofs -dvd-compat -speed=1 -use-the-force-luke=dummy -use-the-force-luke=dao -Z /dev/hdc=movies.iso
Même résultat. Après je me suis plongé dans le code de growisofs. J'ai commencé à rajouter un buffer. Au bout d'un moment, j'ai eu l'idée d'une expérience: j'ai remplacé la boucle d'écriture principale
while ((n=read (infd,the_buffer+off,DVD_BLOCK-off)) > 0)
par
while (1)
ce qui fait que le programme ne lit jamais de données en entrée, et grave le même bloc de 32k encore et encore. Cela m'a permis de tester si c'était la lecture de l'iso par le pipe qui ralentissait le reste.
Hélas, le résultat était toujours aussi mauvais. Ce n'est donc pas un problème de buffer. La seule possibilité que je vois encore pour s'en sortir avec growisofs consisterait à tenter d'optimiser la fonction qui se charge de l'écriture (pwrite64_method). Celle-ci ne travaille qu'avec des blocs de 32k. Est-ce un choix de l'auteur ou une contrainte technique ? Dans le premier cas, il y a peut-être moyen d'augmenter cette taille, en espérant que cela améliore les performances. A creuser, mais sans trop d'espoir...
Pour ce qui est du patch dvd, il est aussi présent dans Debian, sous la forme d'un cdrtools patché, modifié et repackagé sous le nom de dvdrtools. La commande s'appelle dvdrecord ici au lieu de cdrecord-dvd.
Je n'arrive pas du tout à la faire marcher chez moi. Même un -scanbus échoue et retourne:
dvdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open SCSI driver.
Reste encore à teste cdrecord-prodvd.
[^] # Re: les logs
Posté par remyremy . En réponse au message config exim4 pour cegetel. Évalué à 1.
Le 1er grand pas a été de réussir à envoyer un message avec telnet.
J'ai pu ainsi m'apercevoir que je pouvais mettre à peu près n'importe quoi comme nom de site après le ehlo, mais que le domaine de l'adresse de l'expéditeur devait être un domaine existant.
Le plus important est que cela prouvait qu'il n'y avait pas d'authentification ! Et donc pas besoin de me prendre la tête avec TLS !
Par élimination, le problème venait probablement effectivement du fait que exim4 faisait un "ehlo localdomain.localhost" au lieu d'un "ehlo mamachine". J'ai trituré la config avec dpkg-reconfigure exim4-config, sans succès.
Alors je n'ai plus eu le choix. J'ai du faire ce que je redoutais depuis le début... me plonger dans la spécification Exim, un bien bel ouvrage de 50 chapitres.
Et j'ai trouvé !
Il suffit de rajouter la ligne en gras dans le fichier /etc/exim4/exim4.conf.template (à peu près à la ligne 1250 chez moi).
remote_smtp_smarthost:
debug_print = "T: remote_smtp_smarthost for $local_part@$domain"
driver = smtp
helo_data = "mamachine"
hosts_try_auth = ${if exists {CONFDIR/passwd.client}{DCsmarthost}{}}
tls_tempfail_tryclear = false
DEBCONFheaders_rewriteDEBCONF
DEBCONFreturn_pathDEBCONF
J'avoue, j'ai eu la flemme de chercher quelle variable contient le nom de ma machine.
Je sais pas si c'est la manière standard de gérer le problème (j'en doute), mais en tout cas ça marche.
Au bout du compte, j'aimerais quand même comprendre pourquoi ce ehlo est rejeté lors d'un connexion par exim4 alors qu'il est valide par telnet...
Merci hommelix pour ton aide !
[^] # Re: les logs
Posté par remyremy . En réponse au message config exim4 pour cegetel. Évalué à 1.
$ telnet smtp.cegetel.net 25
Trying 212.94.174.24...
Connected to smtp.sitadelle.com.
Escape character is '^]'.
220 smtp.cegetel.net ESMTP Postfix (Debian/GNU)
ehlo mon.adr.esse.ip
250-smtp.cegetel.net
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250 8BITMIME
mail from:xxxxxxx@cegetel.net
250 Ok
rcpt to:xxxxxxxx@cegetel.net
554 <mon.adr.esse.ip>: Helo command rejected: Invalid name
J'ai été surpris de constater qu'il n'y avait pas de ligne 250-AUTH .
Mon nom de machine est arbitraire, je ne suis pas (encore) déclaré sur les serveurs DNS. Est-ce que ça peut jouer ?
Ca n'a probablement rien à voir, mais je ne comprends pas:
$ telnet mon.adr.esse.ip 25
Trying mon.adr.esse.ip...
telnet: Unable to connect to remote host: Connection refused
alors que mon firewall (guarddog) est configuré pour accepter le protocole smtp !?
[^] # Re: dpkg
Posté par remyremy . En réponse au message config exim4 pour cegetel. Évalué à 1.
[^] # Re: les logs
Posté par remyremy . En réponse au message config exim4 pour cegetel. Évalué à 1.
quelquun@laposte.net R=smarthost T=remo
te_smtp_smarthost: SMTP error from remote mailer after RCPT TO:<quelquun@laposte.net>: host smtp.cegetel.net [212.94.174.24]: 554 <localhost.localdomain>: Helo
command rejected: Invalid name