depuis un certain temps, mon forum est régulièrement spammé par un "truc"
(probablement un robot hébergé par un pc zombie) qui cherche a vendre du
viagra ou du valium à qui en veut.
j'ai de fortes raisons de penser que ce "truc" est en fait un bot.
J'aimerais savoir si, sous Perl, on trouve un module sympa, le même qu'en
php, permettant d'afficher une image comportant des caractères alpha
numériques, à faire recopier par l'utilisateur avant de faire quoique ce
soit d'autre, pour vérifier si c'est bien un être humain?
Il paraitrait que cette méthode est de plus en plus contournable, mais cela
me permettrait d'avoir la paix pendant au moins un temps.
Joli ! Dommage que ActiveState ne veuille pas prendre le temps de faire la même chose (il y a peut-être aussi, dans le cas de certains modules ou bibliothèques externes, des problèmes de licences...).
ActiveState utilise un système automatisé pour mettre à jour sa base de paquets ppm directement depuis CPAN : si le module a besoin de bibliothèques externes, la compilation automatique échoue; il faudrait le compiler "à la main", mais ça coute trop cher ! Ils donnent dans la doc des dépots additionnels :
Il y a aussi des problèmes de restriction à l'exportation des modules cryptographiques Crypt::*
Un module qui pose un problème de license est DBD::Oracle. (Oracle no longer provides the Oracle client libraries for free, so we can no longer provide DBD Oracle as a PPM/PPM3 module)
Questions : les bibliothèques externes sont elles-mêmes fournies sous la forme d'un paquet ppm ? Ou s'installent-elles avec chacun des modules Perl qui les utilisent ? Où s'installent-elles ?
La compilation d'un module qui comporte du code XS crée une dll du même nom que celui du module et le place dans C:perlsitelibautoNomDuModule. Si les bibliothèques externes sont liées statiquement à cette dll il n'y a que cette seule dll qui fait tout. Si les bibliothèques externes sont elles- mêmes des dll (donc liées dynamiquement à la dll du module), je les place dans ce répertoire à côté de la dll du module : je suis sûr que ce seront elles qui seront appelées (et non une version éventuellement différente placée dans C:WINDOWSsystem32). Mes paquetages sont complets : si, par exemple, on installe le module OpenGL, il est tout de suite opérationnel (pas besoin d'aller télécharger glut32.dll ou glu32.dll à droite ou à gauche... les programmeurs Perl sont impatients, c'est bien connu ;-)
Question subsidiaire : si un module ou une bibliothèque externe manque, peut-on demander à ce qu'il soit ajouter sur le serveur bribes ?
Bien sûr. J'ai déjà ajouté des modules demandés sur les newsgroups.
Mais ce n'est pas toujours possible. Il faut que le module soit compatible Win32 et, s'il utilise une bibliothèque, il faut qu'elle soit elle-même compatible Win32. Et même dans ce cas ce n'est pas toujours évident...
Un module que l'on m'a souvent demandé est Curses. Le module peut utiliser la bibliothèque PDCurses qui est compatible Win32. Pourtant personne n'a pu compiler le module avec cette bibliothèque.
J'ai cherché pourquoi. J'ai trouvé (péniblement) que PDCurses définit dans son header une variable SP (pour ScreenPointer) qui est utilisée dans le XS du module (par l'intermédiaire d'une macro... donc invisible dans le code) et qui entre en conflit avec le SP (StackPointer) de perl. J'ai donc fait ma petite version de PDCurses en remplacant partout les SP par des SCREENP et j'ai compilé le module sans problème.
Tout ça pour dire que je ne peut pas garantir la compilation d'un module même dans le meilleur des cas.
Mais toutes les demandes seront examinées avec attention et bienveillance ;-)
Quoi ? J'abuse ? ;-)
Mais non, mais non... :-))
-- J-L.M. http://www.bribes.org/perl
Dans l'article <wt9mz1e28ju.fsf@vaugirard.enstimac.fr>, Paul.Gaborit@invalid.invalid a dit...
Joli ! Dommage que ActiveState ne veuille pas prendre le temps de
faire la même chose (il y a peut-être aussi, dans le cas de certains
modules ou bibliothèques externes, des problèmes de licences...).
ActiveState utilise un système automatisé pour mettre à jour sa base de
paquets ppm directement depuis CPAN : si le module a besoin de bibliothèques
externes, la compilation automatique échoue; il faudrait le compiler "à la
main", mais ça coute trop cher !
Ils donnent dans la doc des dépots additionnels :
Il y a aussi des problèmes de restriction à l'exportation des modules
cryptographiques Crypt::*
Un module qui pose un problème de license est DBD::Oracle.
(Oracle no longer provides the Oracle client libraries for free, so we can
no longer provide DBD Oracle as a PPM/PPM3 module)
Questions : les bibliothèques externes sont elles-mêmes fournies sous
la forme d'un paquet ppm ? Ou s'installent-elles avec chacun des
modules Perl qui les utilisent ? Où s'installent-elles ?
La compilation d'un module qui comporte du code XS crée une dll du même nom
que celui du module et le place dans C:perlsitelibautoNomDuModule. Si
les bibliothèques externes sont liées statiquement à cette dll il n'y a que
cette seule dll qui fait tout. Si les bibliothèques externes sont elles-
mêmes des dll (donc liées dynamiquement à la dll du module), je les place
dans ce répertoire à côté de la dll du module : je suis sûr que ce seront
elles qui seront appelées (et non une version éventuellement différente
placée dans C:WINDOWSsystem32). Mes paquetages sont complets : si, par
exemple, on installe le module OpenGL, il est tout de suite opérationnel
(pas besoin d'aller télécharger glut32.dll ou glu32.dll à droite ou à
gauche... les programmeurs Perl sont impatients, c'est bien connu ;-)
Question subsidiaire : si un module ou une bibliothèque externe
manque, peut-on demander à ce qu'il soit ajouter sur le serveur
bribes ?
Bien sûr. J'ai déjà ajouté des modules demandés sur les newsgroups.
Mais ce n'est pas toujours possible. Il faut que le module soit compatible
Win32 et, s'il utilise une bibliothèque, il faut qu'elle soit elle-même
compatible Win32. Et même dans ce cas ce n'est pas toujours évident...
Un module que l'on m'a souvent demandé est Curses.
Le module peut utiliser la bibliothèque PDCurses qui est compatible Win32.
Pourtant personne n'a pu compiler le module avec cette bibliothèque.
J'ai cherché pourquoi. J'ai trouvé (péniblement) que PDCurses définit dans
son header une variable SP (pour ScreenPointer) qui est utilisée dans le XS
du module (par l'intermédiaire d'une macro... donc invisible dans le code)
et qui entre en conflit avec le SP (StackPointer) de perl.
J'ai donc fait ma petite version de PDCurses en remplacant partout les SP
par des SCREENP et j'ai compilé le module sans problème.
Tout ça pour dire que je ne peut pas garantir la compilation d'un module
même dans le meilleur des cas.
Mais toutes les demandes seront examinées avec attention et bienveillance ;-)
Joli ! Dommage que ActiveState ne veuille pas prendre le temps de faire la même chose (il y a peut-être aussi, dans le cas de certains modules ou bibliothèques externes, des problèmes de licences...).
ActiveState utilise un système automatisé pour mettre à jour sa base de paquets ppm directement depuis CPAN : si le module a besoin de bibliothèques externes, la compilation automatique échoue; il faudrait le compiler "à la main", mais ça coute trop cher ! Ils donnent dans la doc des dépots additionnels :
Il y a aussi des problèmes de restriction à l'exportation des modules cryptographiques Crypt::*
Un module qui pose un problème de license est DBD::Oracle. (Oracle no longer provides the Oracle client libraries for free, so we can no longer provide DBD Oracle as a PPM/PPM3 module)
Questions : les bibliothèques externes sont elles-mêmes fournies sous la forme d'un paquet ppm ? Ou s'installent-elles avec chacun des modules Perl qui les utilisent ? Où s'installent-elles ?
La compilation d'un module qui comporte du code XS crée une dll du même nom que celui du module et le place dans C:perlsitelibautoNomDuModule. Si les bibliothèques externes sont liées statiquement à cette dll il n'y a que cette seule dll qui fait tout. Si les bibliothèques externes sont elles- mêmes des dll (donc liées dynamiquement à la dll du module), je les place dans ce répertoire à côté de la dll du module : je suis sûr que ce seront elles qui seront appelées (et non une version éventuellement différente placée dans C:WINDOWSsystem32). Mes paquetages sont complets : si, par exemple, on installe le module OpenGL, il est tout de suite opérationnel (pas besoin d'aller télécharger glut32.dll ou glu32.dll à droite ou à gauche... les programmeurs Perl sont impatients, c'est bien connu ;-)
Question subsidiaire : si un module ou une bibliothèque externe manque, peut-on demander à ce qu'il soit ajouter sur le serveur bribes ?
Bien sûr. J'ai déjà ajouté des modules demandés sur les newsgroups.
Mais ce n'est pas toujours possible. Il faut que le module soit compatible Win32 et, s'il utilise une bibliothèque, il faut qu'elle soit elle-même compatible Win32. Et même dans ce cas ce n'est pas toujours évident...
Un module que l'on m'a souvent demandé est Curses. Le module peut utiliser la bibliothèque PDCurses qui est compatible Win32. Pourtant personne n'a pu compiler le module avec cette bibliothèque.
J'ai cherché pourquoi. J'ai trouvé (péniblement) que PDCurses définit dans son header une variable SP (pour ScreenPointer) qui est utilisée dans le XS du module (par l'intermédiaire d'une macro... donc invisible dans le code) et qui entre en conflit avec le SP (StackPointer) de perl. J'ai donc fait ma petite version de PDCurses en remplacant partout les SP par des SCREENP et j'ai compilé le module sans problème.
Tout ça pour dire que je ne peut pas garantir la compilation d'un module même dans le meilleur des cas.
Mais toutes les demandes seront examinées avec attention et bienveillance ;-)
Quoi ? J'abuse ? ;-)
Mais non, mais non... :-))
-- J-L.M. http://www.bribes.org/perl
Emmanuel Florac
Le Thu, 12 Apr 2007 09:01:16 +0000, Nicolas George a écrit :
faire une version texte des captchas, bof...
:)
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Le Thu, 12 Apr 2007 09:01:16 +0000, Nicolas George a écrit :
faire une version texte des captchas, bof...
:)
--
Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir
aristocratique de déplaire.
C. Baudelaire.
