[toulouse-pm] Une liste rigolote...

Michel Rodriguez mrodrigu at xmltwig.com
Mon Oct 14 03:34:13 CDT 2002

...et dans laquelle j'ai reconnu pas mal de conneries que j'ai faite


I did not really learn everything I know about Perl from Kurt Starsinic
(Randal Schwartz gets that distinction :), but it was not until we started
to work together that I started to keep track of the things I learned,
mostly from debugging modules. All of these tips comes from real-life
mistakes I personally made and Kurt from time to time helped me discover:

    * Keys don't show up in hashes unless I create them
    * Arrays don't have anything in them until I add elements to them.
    * If I assign a scalar a new value that it shouldn't have, it no
      longer has the value it should have.
    * If I want to use the DBI module, I need to install it.
    * If I modify a reference, the data changes.
    * If I want to call the subroutine foo(), I shouldn't spell it "bar".
    * "true" is always numerically equal to "false"
    * "true" is always numerically equal to undef
    * If I assign a value to a string, it replaces the old value rather
      than appending to it (lesson: .= is not the same as =).
    * I can't expect Perl to load CGI.pm just because I say CGI->new().
      (But wouldn't that be cool!) [Node de mirod: Brian Ingerson a des
      idees la dessus, NAPC, voir plus bas)
    * A script still acts broken unless I save the changes.
    * mod_perl modules still act broken unless it reloads the modules.
    * CVS still has the old version until I commit the changes (which
      means everyone else has the old changes).
    * If I ssh to a remote machine and take down the network interface, I
      cannot ssh to the machine to bring it back up (took me three tries
      to learn this one---lesson: terminal servers good! brian sysadmin
    * Regular expressions don't match anything in a null string in a
      variable name I spelled incorrectly.
    * strict doesn't work unless I use it (see prior tip).
    * Although Perl lets me use really long names, I shouldn't create
      variables like
      $this_client_really_sucks_and_will_never_see_this_code = 6
      (true story---actually did that and someone sent it to the client
      without looking at it).
    * Don't make changes after code freeze and right before Randal reviews
      the code. He'll bust me on it (and has) because it almost is always
      bad code.
    * Tests don't run unless I create them.
    * Warnings don't go away if I just keep running the script (although
      if Perl were upgraded...).
    * unlink returns the number of files I need to restore from backup,
      but not their names.
    * If I muck with the Perl source and don't tell anyone and they
      recompile a perl for themselves, their perl probably won't work.
    * Always grab clean sources (see prior tip).
    * Always muck with sources in your own directory, not the stuff in
    * If I don't make the cable a cross-over cable, it doesn't act like a
      cross-over cable.
    * I must be connected to the network to fetch pages with LWP (wouldn't
      it be cool if all these wires went away...oh wait, they did!)
    * Perl programs that I think will run fast don't and ones that I think
      will run slowly do.
    * If I write a Python construct in a Perl script, Perl will give me an
      error (unless I use one of them fancy Damian modules).
    * Files aren't easier to open the 40th time I try (lesson: the
      directory has to exist---check $!).
    * Don't trust programs that compile on the first shot (all those
      syntax errors turned into logic errors).

And, the most important lesson I learned about using Perl:

    * Wait three days to tell them I'm done, even if I wrote the script in
15 minutes.

A propos de NAPC, qui ne semble pas avoir bouge beaucoup depuis l'an
dernier: ca serait un systeme qui permettrait de faire juste
use NAPC;   # je suppose
use Module; # Module n'est pas forcement installe sur la machine

Je crois que j'en ai deja parle l'an dernier parce que c'est un systeme
qui me semble interessant, et surtout que si on resoud les problemes qu'il
pose on pourra faire plein d'autre trucs sympa, genre P2P avec l'assurance
de bien recuperer ce qu'on cherchait. En brefle ca devrait ressembler a

use NAPC;   # je suppose
use Module; # Module n'est pas forcement installe sur la machine

Si le module n'est pas installe NAPC cherche sur le reseau une machine de
meme type qui a le module (donc ca marche meme pour les modules compiles,
sans avoir besoin d'un compilo installe), le recupere et l'installe (au
moins pour l'utilisateur courant). C'est le principe d'Inline: la premiere
fois que le code tourne le C est compile et cache dans un repertoire
local, les fois suivantes il est la, pret a etre utilise.

Quelques infos glanees sur le web (mais pour l'instant il semble que ce
soit essentiellement dans la tete, et peut etre dans le Mac, d'Ingy):


After lunch it was time for a talk about NAPC and CPANTS. NAPC is inspired
by Napster and is, well, something to enhance CPAN. Brian Ingerson talked
about NAPC and started it by...singing.


Brian Ingerson's NAPC project to make the downloading and installing
of modules much easier has prototype code!  Neil has layed down the
basics of the server and the three of us worked out the last of the
major design issues.  The three of us will meet up again at
YAPC::Europe in a few days, so hopefully a working prototype will


dans la meme thread, un message interessant de Brian Ingerson


NAPC is a project for improving many of the current setbacks of the CPAN

Michel Rodriguez
Perl & XML

More information about the Toulouse-pm mailing list