This release has been made possible by six people, so it’s quite the first community-driven release of Dancer, and nothing could make me more happy than that.

I really like the fact that different people, from different places come and contribute ideas, documentation and patches. This is how open source works, and this is how great tools are written. I’m glad to see Dancer taking that path. I can only hope that it will be like that for a long time.

This new version provides mostly bugfixes and documentation updates. See the changelog for full details. Oh, and thanks to David Precious, we now have a shiny Cookbook!

Major new features will come with 1.160, but that’s for another blog entry ;)

Enjoy your dances.

Related posts:

1. Perl Dancer 0.9904 released I’ve just published a new version of Dancer. It’s basically...
2. Dancer 1.100 released A new version of Dancer has just been published on...
3. Dancer 1.18 released I’m glad to announce a new major release of Dancer,...

    * Support for multiple method routes at once with 'any'
    * Templates engines
      + Bug fixes in Dancer::Template::Simple (Jury Gorky)
      + Refactoring of the factory
      + option for disabling the layout in the template helper.
    * New session engine based on encrypted cookies (Alex Kapranof)
    * More HTTP codes supported for a better REST compat (Nate Jones)
    * Documentation updates
    * script/dancer now requires an appname
    * New Makefile.PL with better metadata (CPAN Service)

I’m pretty glad to underline that this release is the first one where most of the changes are written by other developers than me, that’s really exciting to see more and more people involved with the project.

This release should also fix the test-suite which looks to be broken on most of the CPAN testers under version 1.000 (but sadly not on my workstation, so I wasn’t aware of it).

UPDATE Jan. 7th 2010 : The CPAN-testers reports show that 1.100 passes 100% of the tests under Linux and FreeBSD, that’s a good start!
Stay tuned for next dances!

Related posts:

1. Dancer 1.150 released I’m happy to announce the release of Dancer 1.150. This...
2. Perl Dancer 0.9904 released I’ve just published a new version of Dancer. It’s basically...
3. Dancer 1.18 released I’m glad to announce a new major release of Dancer,...

Major changes for this version are the following:

• Support for cookies
• Support for YAML-file-based sessions
• Support for Memcached-based sessions
• Support for Syslog logging
• Less dependencies than ever (only HTTP::Server::Simple and Exception::Class are mandatory to start writing a Dancer app)

The test suite has also been heavily enhanced, covering now more than 80% of the source code.

I’ve just uploaded the tarball to the CPAN, so expect it to be cpan-able in the next couple of hours.

I welcome very much feedback on this release, please feel free to give it a try ;)

Bugs reports are also welcome here.

Oh, and by the way, today is a special day ;-)

Related posts:

1. Dancer 1.100 released A new version of Dancer has just been published on...
2. Perl Dancer 0.9904 released I’ve just published a new version of Dancer. It’s basically...
3. Session support for Dancer, 1.0 is near I’m glad to write this blog entry: Dancer now supports...

Rached me l’a fournie en fin de journée au boulot : il a mis le doigt sur une brêche dans les perfs de Coat lorsque l’on utilise la coercition (coerce dans Coat). La chute de perfs était due à une utilisation de Carp::confess, catchée par un bloc eval, ce qui est très mal, car à chaque fois que Perl utilise confess, il va chercher toutes les infos de la pile d’appel, ce qui est couteux.

Le mécanisme de coercition de Coat utilise désormais une méthode silencieuse qui retourne un booléen au lieu de faire un confess, on évite ainsi de ruiner les performances.

Outre ce correctif important, la version 0.334 apporte le support de BUILDARGS qui vous permet de construire vos arguments lors de l’instanciation d’objets.

Je viens d’uploader le package sur CPAN, donc d’ici quelques heures ça devrait être dispo ici.

EDIT : 25 Nov. 2008, 10:07

Après quelques retours sur ce billet je m’aperçois que je parle trop vite et que certains ont eu la curiosité éveillée, je m’empresse de préciser donc :

Qu’est-ce que la coercition

La coercition est un mécanisme qui permet de transformer à la volée une valeur d’un champ dans un format particulier. La coercition est utilisée pour modifier une valeur qui ne valide pas le type d’un attribut mais qui valide un type défini dans une coercition.

Un exemple simple : j’ai une classe qui possède un attribut “mysql_date” qui est valdie le format : YYYY-MM-DD. Je peux définir une coercition sur cet attribut pour toute valeur qui validerait le type ‘Timestamp’ par exemple.

Ainsi je pourrai faire

$mon_objet->mysql_date( time() );

La coercition entrera donc en jeu et convertira l’entier retourné par time() en une date formatée selon la règle définie par l’utilisateur.

Quel était le problème avec confess/eval ? Est-ce mal d’utiliser confess ?

La chute de performance n’était pas due directement à confess, mais plutôt à l’utilisation que le mécanisme de coercition en faisait. Lorsqu’une valeur ne validait pas le type premier d’un attribut et qu’une coercition était définie, Coat bouclait sur toutes les coercitions définies afin de voir si la valeur validait le type source de la coercition. Or cette validation était faite avec le mécanisme standard de Coat qui déclenche une exception avec confess si la valeur n’est pas valide. Coat utilisait donc un bloc de code dans eval pour savoir si oui ou non la valeur est acceptée.
C’est ici que le problème réside : on ne veut pas d’exception, on veut une réponse booléene, inutile donc de faire appel à confess (et donc de lire la pile d’appel), il nous faut une méthode de validation silencieuse, qui retourne 1 ou 0 selon la validité du champ.

On peut donc résumer en disant que confess ne pose aucun problème tant qu’il est utilisé uniquement pour interrompre l’exécution du programme, et surtout pas pour être catché afin d’avoir une réponse à une question booléene.

Pour les gens intéressés, le diff est dispo ici, on constate également que la construction du message en cas d’exception était également couteuse, puisqu’elle fait appel a un bloc de code (les messages d’erreur de coercition sont des blocs de code, afin de pouvoir expander $_).

Qu’est-ce que BUILDARGS

Cette fonctionnalité vous permet de définir une méthode BUILDARGS dans votre classe. Lorsqu’un objet de cette classe est instancié, la méthode est appelée avec les arguments donnés à l’instanciation. Elle peut à loisir modifier les arguments et la valeur qu’elle retourne sera la structure de données finale reçue par l’instanciation.

On peut dire qu’il s’agit un pre-processing des arguments d’instanciation. Combiné avec une méthode BUILD ça peut être très combo-magique :-)

Voilà, j’éspère que ces précisions sont claires (je n’en suis pas sûr: c’est le matin et je n’ai pas bu mon café). Les commentaires sont là si vous avez des questions.

Related posts:

1. De la bonne façon de manipuler le temps avec Coat::Persistent Soit la situation suivante : vous avez une classe qui...
2. Publication de Coat::Persistent 0.200 Je viens d’uploader Coat::Persistent sur CPAN. Voila une bonne chose...
3. Coat::Persistent aux Journées Perl 2009 Je reviens à l’instant des Journées Perl 2009. La conférence...