Discussion :

[djibril]

Bonjour,

Je lance ce débat pour parler d'ActivePerl. En fait, il y a quelques années, il n' y avait que la version 5.8 (pour ne pas parler de la 5.6) qui évoluée régulièrement. Pendant ce temps, le développement de la 5.10 suivait son cours. Puis, nous nous sommes retrouvés avec 2 versions en évolutions. Il a fallu quelques mois pour espérer avoir nos sympathiques modules Perl du CPAN compatibles sur les deux versions. Maintenant la politique d'ActivePerl est de proposer une version stable chaque année. C'est intéressant car Perl est très maintenu et évolue bien, mais sincèrement, on se retrouve avec x versions de Perl et on s'y perd. Actuellement, il y a 4 versions d'ActivePerl 5.8, 5.10, 5.12 et 5.14, et je ne parle pas de Perl6, Parrot, Strawberry... mais ce n'est pas le but du débat. Le pire dans tout ça, c'est qu'au niveau de l'installation des modules, ça se corse car tous les repositories n'arrivent pas toujours à compiler et packager tous les modules CPAN (très grande force de Perl). Ainsi, ActivePerl nous recommande la version 5.12 (et il y a quelques semaines, il préconisait la 5.14, plus l'on enlevé de la tête d'affiche). Mais au niveau des modules, on se retrouve avec beaucoup moins de modules à installer facilement via ppm sous Windows par exemple. Rien qu'à voir le site Active Code PPM index :

• 5.8.8 le 31 janvier 2006
• 5.10.0 le 18 décembre 2007, 20e anniversaire de Perl 1.000
• 5.8.9 le 14 décembre 2008
• 5.10.1 le 23 août 2009
• 5.12.0 le 12 avril 2010
• 5.12.1 le 16 mai 2010

On remarque la baisse du nombre de modules dans ppm en fonction des version de Perl. Sachant qu'il y a une version stable prévue chaque année au mois de juin !!!
Je viens également de constater qu'ActivePerl ne propose plus en téléchargement gratuit les versions de perl 5.6, 5.8 et 5.10

Community Edition offers access to the newest versions of ActivePerl.
Access to older versions (such as Perl Perl 5.6, 5.8, or 5.10) is available in Business Edition and Enterprise Edition......
...

• Community Edition: commercial-grade language distribution ideal for community developers with open source projects
• Business Edition: commercial-grade language distribution, ideal for SMB and government with business critical applications
• Enterprise Edition: enterprise-grade language distribution, ideal for large enterprises with mission critical applications
• OEM Edition: enterprise-grade language distribution with redistribution rights for software & hardware

Jusqu'où va-t-on aller ? On risque de se retrouver avec beaucoup de modules qui ne seront compatibles qu'avec les versions 5.10, 5.12 ou 5.14... et du coup être privée de certaines fonctionnalités du CPAN, non ?

Qu'en pensez-vous ?

[pomoxp]

Bonjour

j'ai débuté cette réflexion de changer de version Perl (5.8 actuellement) depuis un peu plus d'un an.
Et depuis le début j'ai constaté l'arrivée respective des versions 5.10, 5.12 et désormais 5.14

Cela s'explique par le fait que la communauté active Perl a décidé d'accélérer la production de nouvelles Releases : c'est un bien mais c'est aussi un casse-tête puisqu'il faut gérer ces montées de version.
Il faut du même coup gérer les modules CPAN que l'on souhaite rajouter.

En parallèle, la société ActiveState a décidé de définir un modèle de support payant et ne propose gratuitement plus que 2 portages (Win et Linux) et seulement sur les dernières versions de Perl.

Au départ je pensais me baser sur ActivePerl pour Win,Linux,Sun,Aix afin d'avoir une version identique (à 99%) mais avec ce nouvelle modèle payant, nous devons revoir notre décision.

Jusqu'où va-t-on aller ? On risque de se retrouver avec beaucoup de modules qui ne seront compatibles qu'avec les versions 5.10, 5.12 ou 5.14... et du coup être privée de certaines fonctionnalités du CPAN, non ?

Pour l'instant, j'en suis à dire que je vais recompiler une version Perl choisie récente mais pas la dernière sortie (5.12 à ce jour) pour toutes mes plateformes avec les modules CPAN nécessaires.
Et du coup je limite volontairement les modules disponibles, cela implique de bien identifier les modules nécessaires.
Je cogite...

Voilà ma réponse qui n'en est pas une mais plus une remarque

[djibril]

C'est sûr que l'évolution active de Perl en soit est une bonne chose. Rien qu'à lire les releases :

What's New in ActivePerl 5.14

The "unicode_strings" feature is now fully functional
Exceptions are now more reliable
The s/// substitution operator has a new non-destructive /r option to work on a copy of the string
For list of all new features, see the ActivePerl 5.14 documentation

What's New in ActivePerl 5.12 (Latest release: 5.12.1.1202)

Based on Perl 5.12.2
Additional modules, including Perl::Critic, Devel::NYTProf and Moose
GUI shell for Perl::Critic
y2038 compliance
Unicode improvements
Support for pluggable keywords
For a complete list of changes, see the ActivePerl 5.12 release notes.

What's New in ActivePerl 5.10 (Latest release 5.10.1.1007)

PPM scans .packlist files newer than the corresponding PPM database for that install area
On 32-bit Windows CPAN shell automatically downloads and installs the MinGW GCC compiler
Modules shipped as part of core Perl now included in PPM database
Bundled modules updated to latest version
Security fixes
For a complete list of changes, see the ActivePerl 5.10 release notes.

What's New in ActivePerl 5.8 based on Perl 5.8.9 (Latest release 5.8.9.827)

OpenSSL security fixes
-p filetest implemented on Windows
PerlEx no longer pretends to be mod_perl
Potential memory corruption in Perl for ISAPI fixed
Bundled modules updated to latest version
For a complete list of changes, see the ActivePerl 5.8 release notes.

Perl 5.14

Selon la Perl Foundation, cette nouvelle version 5.14 représente un an de développement, et 550 000 lignes de modifications
sur près de 3000 fichiers de code source. Ces fichiers sont principalement ceux du CPAN, le réseau de modules Perl
prêts à l'emploi. Ces modifications sont de plusieurs genres : meilleur support d'IPv6, amélioration des performances,
sans compter une très forte contribution aux fichiers de documentation.

Perl évolue à très grande vitesse, c'est très bien. Le seul souci, c'est qu'un nouveau développeur Perl qui voudra profiter des dernières forces de Perl et mettre à la disposition du CPAN un module risquera d'utiliser des nouvelles syntaxes du langage (ce qui est compréhensible). Ainsi, une personne ayant installer la version 5.12 par exemple un avant la sortie de la 5.14 ne pour même pas profiter de ce module. Je trouve cela un peu limite vu qu'il y a une grosse realease par an .

[dourouc05]

C'est le même problème qui a fini en un référendum pour Python, accouchant de Python 3, aucune modification de syntaxe pendant toute la release, avec un gros paquet d'incompatibilités avec la série 2.x. C'est sûrement l'un des objectifs de Perl 6 que de se débarrasser de la syntaxe devenue obsolète et de la stabiliser, non ?

[Philou67430]

Perso, j'ai laissé de coté l'implémentation d'ActiveState pour me baser sur celle de cygwin, à mes yeux plus proche de l'implémentation U*ix, notamment pour écrire les unilignes, la gestion des modules du CPAN.
Cette implémentation a cependant des limitations (support des librairies graphiques, versions tributaires des publications de Cygwin/redhat).

En revanche, je pense que ces problèmes d'implémentations de perl 5 n'ont rien à voir avec le développement de perl 6, que l'on doit, à mes yeux, considérer comme un nouveau langage, et non comme une évolution de perl5.

[djibril]

C'est sûr qu'on a tendance à prendre perl6 comme une évolution ou release de perl5, mais en fait, ce sera bien un nouveau langage.

[djibril]

Les choses se gatent sur ActivePerl.

Maintenant une personne ayant une version d'ActivePerl qui est passé du coté Business ne pourra plus bénéficier du repository d'ActivePerl pour l'installation des modules CPAN. Super cette politique sachant qu'il y a une version tous les ans.

Pour information, voici un exemple de message d'erreur que vous pouvez avoir dans ppm à la suite d'installation de modules (source) :

Question:

PPM gives me a 401 Authorization Required. Why?
Answer:

The repository you are accessing contains exclusively Business Edition content. If you do not have a Business Edition license installed on the system, the PPM server will advise that you are not permitted to access the directory.

Perl versions move into Business Edition when the Perl Community is no longer actively supporting that version of Perl. ActiveState policy for PPM is that free and open access to PPM binary modules for versions that have moved entirely into Business Edition will continue for *at least* six months beyond the date at which the no Community Edition versions of that Perl are available.

All versions of Perl 5.8 and 5.10 required Business Edition licensing in 2010.
All versions of Perl 5.12 required Business Edition licenses as of September 2012.

[Philou67430]

C'est qu'il est temps de passer à Strawberry

[djibril]

Bon,

Ayant quelques soucis avec ActivePerl sous 64 bits avec Per 5.18, je migre vers Strawberry 5.20 directement et pour el moment, j'en suis satisfait .
Affaire à suivre !

[Lolo78]

A mon avis, Activeperl déconne à plein tube. Il vaut mieux oublier pour le moment. Srawberry fait bien mieux. Et Cygwin encore mieux.

[dmganges]

Bonjour,

Etant un petit utilisateur de Perl mon avis est de peu d'importance.
Perso j'utilise encore la 5.12 j'y suis vite revenu après une tentative de la 5.18 où j'avais des pb avec des modules.
Comme je n'utilise pas de modules "extravagants", et étant pressé je n'ai pas cherché à les résoudre...

Ayant quelques soucis avec ActivePerl sous 64 bits avec Per 5.18, je migre vers Strawberry 5.20 directement et pour el moment, j'en suis satisfait .
Affaire à suivre !

Que donne les modules de la 5.12 ActivePerl avec la Strawberry 5.20

[Edit 09:58] : Vu la réponse, MERCI !

[djibril]

Tu peux toujours participer au sondage et donner ton avis.

[Philou67430]

A mon avis, Activeperl déconne à plein tube. Il vaut mieux oublier pour le moment. Srawberry fait bien mieux. Et Cygwin encore mieux.

Cygwin/perl vient avec des limitations, et strawberray avec d'autres. Dans le registre des limitations de Cygwin, j'ai souvent des soucis avec les interfaces graphiques (notamment Tk pour lequel certains Widget partent en exception alors qu'ils fonctionnent très bien avec Strawberry).
Du coté de Strawberry, j'ai longtemps eu des soucis avec la navigation dans l'historique du débugger avec les flèches hautes et basses, normalement réglé (sur les autres plateformes) par l'installation de Term::ReadLine::Gnu. Mais cette installation échoue sur Strawberry par manque de librairies C dans le toolkit gcc inclus. Je ne sais pas quel miracle ça marche à présent... alors que Term::ReadLine::Gnu n'est pas installé.

Sinon, ma préférence va aussi vers Cygwin pour la plupart des usages... notamment pour les apports autres que Perl que fournit Cygwin.