Functional Mind

Hoy por casualidad he encontrado esta referencia, Let Over Lambda, Closures de Doug Hoyte. Es curioso que sin haberlo leído antes, la solución que he dado al problema de extraer la descripción de una entrada del blog sin tags HTML ha sido así usando un closure.

Como véis, todavía no funciona la búsqueda en el blog, pero tengo una idea muy interesante para implementarla. Recordad que el blog se genera estáticamente, así que no puedo depender de ningún proceso de servidor, así que, por decirlo de alguna manera, tengo que precalcular la búsqueda y almacenarla en algún sitio, que además, no entorpezca con el blog (no tarde más tiempo en cargar, por ejemplo). Lo que estoy preparando lo explicaré con tranquilidad. Por ahora, valga una muestra de lo que llevo implementado:

BLOG> (hash-table-count
       *words-to-post-hash*)
18119

18119 palabras diferentes. Ahora los posts que contienen "corba", y sus títulos:

BLOG> (gethash "corba" *words-to-post-hash*)
(#<POST {100A12E8A1}> #<POST {100A12E881}> #<POST {100A12E521}>
 #<POST {100A12E4E1}> #<POST {100A12E4C1}> #<POST {100A12E3E1}>
 #<POST {100A12E021}> #<POST {100A12DBA1}> #<POST {100A12D321}>
 #<POST {100A12CEE1}> #<POST {100A12C821}> #<POST {100A12C641}>
 #<POST {100A12C5A1}> #<POST {100A12C361}> #<POST {100A12C2E1}>
 #<POST {100A12B4E1}> #<POST {1003344011}> #<POST {1003343EB1}>
 #<POST {10033437B1}> #<POST {10033436B1}> #<POST {1007887F81}>
 #<POST {1007887221}> #<POST {10078870A1}> #<POST {1007886801}>)
T
BLOG> (mapcar #'post-title (gethash "corba" *words-to-post-hash*))
("¿Por qué un Weblog?" "5.000.000.000" "CCM page, reloaded"
 "Recent articles on CCM" "German book on CCM" "CCM Wiki updated"
 "Some thoughts on Web Services" "New version of the CCM tutorial"
 "Stefan Tilkov on RPC Web Services" "Trabajo en la tesis" "CORBA Reborn?"
 "Interesting post on XML messaging by Stefan Tilkov" "Sistemas Distribuidos"
 "Prácticas de Sistemas Distribuidos" "Un día de trabajo con mi tesis" "FreeNX"
 "Fowler, inversion del control" "Ser profesor tiene sus cosas buenas"
 "Función C++ rara del día" "The S stands for Simple"
 "Conversión sencilla de tipos CORBA" "Parecía que nunca iba a llegar..."
 "Más avances: Cátedra SAES-UMU" "SOAP, entre lo peor de la década")

Lo cual es, por cierto, una magnífica lista de entradas para esa palabra... Esta información también me permitirá añadir al final un conjunto de "posts relacionados" en cada entrada.

Iba a introducir imágenes en el blog y he querido escribir una pequeña función que hace más sencillo introducir fácilmente las imágenes con la ruta por defecto, y, si procede, un enlace para las mismas. La función queda como sigue:

(defun blog-img (img-file &key alt anchor title params)
  (let* ((param-list
          (cons `(src . ,(format nil "~A/~A" *base-img-url* img-file))
                (cons `(alt . ,(or alt "Blog image.")) ; alt is obligatory
                      (when title `((title . ,title))))))
         (param-list-1 (append param-list params))
         (img-html (img param-list-1)))
    (if anchor
        (a `((href . ,anchor)) img-html)
        img-html)))

¿No es bonito? En particular me gusta el uso del seudoquote. Las funciones img y a generan el HTML para las imágenes y para los enlaces, respectivamente. Un ejemplo de uso de esa función sería:

(blog-img "abc.jpg" :alt "Alt text" :params '((:width . 500)))

donde se elige el fichero img/abc.jpg con un texto alternativo y con el conjunto de parámetros adicionales, entre ellos el ancho de la imagen. Si se especifica un elemento anchor el código que se genera es el siguiente:

(blog-img "abc.jpg" 'anchor "http://wherever.com"  'alt "bah" 'params '(('width . 500)))

<A HREF="http://wherever.com"><IMG SRC="img/abc.jpg" ALT="bah" WIDTH="500"></IMG></A>

De cara a optimizar la generación de las páginas del blog con multiprogramación, he querido registrar el tiempo que tarda en ejecutar la generación en el ordenador que se genera, para compararla después con la optimización. Para mi sorpresa, la mayor parte del os 8 segundos que lleva la generación se la lleva el leer y compilar el fichero Lisp que contiene las entradas antiguas (1.3MB), mientras que la generación de todas las páginas no tarda más de 4 segundos:

[dsevilla@neuromancer:~/svn/blog]$ sbcl --script packages.lisp
Doing pre-calculations...
Generating index page...
Evaluation took:
  0.116 seconds of real time
  0.120000 seconds of total run time (0.080000 user, 0.040000 system)
  [ Run times consist of 0.040 seconds GC time, and 0.080 seconds non-GC time. ]
  103.45% CPU
  325,871,901 processor cycles
  63,697,264 bytes consed

Generating post pages...
Evaluation took:
  0.408 seconds of real time
  0.410000 seconds of total run time (0.270000 user, 0.140000 system)
  [ Run times consist of 0.010 seconds GC time, and 0.400 seconds non-GC time. ]
  100.49% CPU
  1,144,029,612 processor cycles
  167,055,120 bytes consed

Generating categories pages...
Evaluation took:
  0.074 seconds of real time
  0.070000 seconds of total run time (0.070000 user, 0.000000 system)
  94.59% CPU
  209,026,050 processor cycles
  39,985,040 bytes consed

Generating archives pages...
Evaluation took:
  0.086 seconds of real time
  0.090000 seconds of total run time (0.090000 user, 0.000000 system)
  104.65% CPU
  240,093,459 processor cycles
  43,278,720 bytes consed

Generating RSS...
Evaluation took:
  0.084 seconds of real time
  0.080000 seconds of total run time (0.080000 user, 0.000000 system)
  [ Run times consist of 0.020 seconds GC time, and 0.060 seconds non-GC time. ]
  95.24% CPU
  236,784,003 processor cycles
  35,828,208 bytes consed

Esto hace que la optimización, como máximo, sólo pueda reducir esos 0,4 segundos que tarda la generación. Aún así lo intentaré como un ejercicio de programación. La otra idea será ver optimizar el proceso de carga quizá a través de pre-compilación de los ficheros .lisp. Por cierto, para que luego digan que los lenguajes interpretados son lentos... 1 segundo en generar 34MB de ficheros de texto.

La última sorpresa... Por casualidad he probado clisp... Bien, aquí la carga de los ficheros .lisp es instantánea, y la ejecución es incluso más rápida (diría incluso increíblemente rápida:

[dsevilla@neuromancer:~/svn/blog]$ clisp packages.lisp
Doing pre-calculations...
Generating index page...
Real time: 0.186066 sec.
Run time: 0.19 sec.
Space: 24960736 Bytes
GC: 13, GC time: 0.03 sec.
Generating post pages...
Real time: 0.708989 sec.
Run time: 0.69 sec.
Space: 83706152 Bytes
GC: 36, GC time: 0.06 sec.
Generating categories pages...
Real time: 0.051339 sec.
Run time: 0.05 sec.
Space: 11157832 Bytes
GC: 5, GC time: 0.0 sec.
Generating archives pages...
Real time: 0.249124 sec.
Run time: 0.25 sec.
Space: 13408648 Bytes
GC: 6, GC time: 0.02 sec.
Generating RSS...
Real time: 0.891364 sec.
Run time: 0.88 sec.
Space: 20991880 Bytes
GC: 9, GC time: 0.05 sec.

Comparando el tiempo de ejecución visto por el usuario:

[dsevilla@neuromancer:~/svn/blog]$ time clisp packages.lisp
real	0m2.320s
user	0m1.970s
sys	0m0.310s

[dsevilla@neuromancer:~/svn/blog]$ time sbcl --script packages.lisp
real	0m10.405s
user	0m9.940s
sys	0m0.440s

Esto es, ¡5 veces más rápido en general clisp que sbcl! Sin embargo, mirando los datos de cada parte, hay resultados muy extraños e inconsistentes. Por ejemplo, clisp tarda casi un segundo en generar RSS, mientras que sbcl tarda 0,08 segundos (un orden de magnitud menos). Estudiaré el código para ver dónde puede estar el problema, pero por ahora, usaré clisp para generar el blog, aunque use sbcl, con el magnífico entorno Slime para Emacs para seguir programando y probando.

Siguiendo este enlace voy a intentar añadir multiprocesamiento a la generación del blog para acelerarlo. No va a ser tan sencillo como debería ser, por ejemplo, debería existir, como en Clojure, un parallel map pero la verdad es que no hay, sólo hilos tradicionales... La ventaja, sin embargo, será grande, ya que todas las páginas se pueden generar en paralelo.

Pues no ha sido complicado. Simplemente he seguido las instrucciones del README de la página de google-code-prettify y ya está.

Sólo por curiosidad, he aquí cómo está implementada la generación de los links con diferente tamaño del sidebar:

(defun categories-links ()
  (if *categories-links*
      *categories-links*
      (setf *categories-links* (multiple-value-bind (max-n-posts min-n-posts)
          (loop for c being the hash-values in *posts-for-category*
             maximizing (car c) into max
             minimizing (car c) into min
             finally (return (values max min)))
        (apply #'concatenate 'string
                (loop for k being the hash-keys in *posts-for-category*
                   using (hash-value v)
                   collect (format nil "<a href=\"category-~A.html\"
                             title=\"~A topic~:*~p\" rel=\"category tag\"
                             style=\"font-size: ~Apx;\">~3:*~A</a> "
                             (string-downcase k)
                             (car v)
                             (+ 9 (round
                                   (/ (- (car v) min-n-posts)
                                      (/ (- max-n-posts min-n-posts) 10)))))))))))

Y eso sin contar con el cálculo de *posts-for-category*.

Esta es la primera entrada de este nuevo blog cuyo generador está escrito en Common-Lisp. ¿Lisp? Sí, más de 50 años después sigue vivo, y sinceramente, es una maravilla aprenderlo y usarlo. Iré mostrando en el futuro cómo se genera.