Saltar a contenido

2012

Emacs y análisis estático de código en python

Gracias a Cartolab he podido seguir dándole una vuelta al análisis de código estático en python. La idea era reducir los incómodos errores que se producen porque te equivocas al escribir el nombre de una variable o cosas parecidas de las que no te das cuenta has que ejecutas el código. Tratar de detectar estos errores de la forma en que lo veíamos en el artículo anterior sigue sin ser demasiado productivo y aquí es donde entra en juego la extensión para emacs Flymake.

Lo que hace Flymake es «pedirle» a emacs que esté continuamente realizando ciertos análisis sobre el código o tratando de compilarlo y/o ejecutarlo. En realidad flymake es un plugin bastante genérico que funciona del siguiente modo:

  1. Si al abrir un nuevo buffer está marcado como «a chequear», flymake programa un temporizador para el buffer. La forma de marcar buffers suele ser en función de la extensión del archivo que abramos
  2. Crea una copia temporal de los buffers abiertos cada cierto tiempo
  3. Ejecuta un programa externo sobre la copia del buffer. Este programa puede ser gcc, make u otra cosa como una herramienta de análisis estático de código.
  4. Parsea la salida que produce el programa externo y da una salida visual en el buffer actual para representar los posibles errores.

Activar flymake

Activar flymake junto a alguna de las herramientas que veíamos en el post anterior es bastante fácil. Flymake viene instalado por defecto, así que sólo tenemos que tener en el path los ejecutables a las herramientas de análisis, y añadir a nuestro .emacs las instrucciones para que se activen con los ficheros python.

flymake con pyflakes:
<br></br>(when (load "flymake" t)<br></br>(defun flymake-pyflakes-init ()<br></br>(let* ((temp-file (flymake-init-create-temp-buffer-copy<br></br>'flymake-create-temp-inplace))<br></br>(local-file (file-relative-name<br></br>temp-file<br></br>(file-name-directory buffer-file-name))))<br></br>(list "pyflakes" (list local-file))))<br></br>(add-to-list 'flymake-allowed-file-name-masks'("\\.py\\'" flymake-pyflakes-init)))<br></br>

flymake con pylint (el comando epylint es un modo especial de pylint para trabajar con emacs)
<br></br>(when (load "flymake" t)<br></br>(defun flymake-pylint-init ()<br></br>(let* ((temp-file (flymake-init-create-temp-buffer-copy<br></br>'flymake-create-temp-inplace))<br></br>(local-file (file-relative-name<br></br>temp-file<br></br>(file-name-directory buffer-file-name))))<br></br>(list "epylint" (list local-file))))<br></br>(add-to-list 'flymake-allowed-file-name-masks'("\\.py\\'" flymake-pylint-init)))<br></br>
flymake con pep8
(when (load "flymake" t)<br></br>(defun flymake-pylint-init ()<br></br>(let* ((temp-file (flymake-init-create-temp-buffer-copy<br></br>'flymake-create-temp-inplace))<br></br>(local-file (file-relative-name<br></br>temp-file<br></br>(file-name-directory buffer-file-name))))<br></br>(list "pep8.py" (list "--repeat" local-file))))<br></br>(add-to-list 'flymake-allowed-file-name-masks'("\\.py\\'" flymake-pylint-init)))<br></br>

Por otro lado también podriamos configurar flymake para hacer que se pasarán las tres herramientas de forma automática pero yo lo veo innecesario dado que la información que proporcionan es en muchos casos redudante y estamos disminuyendo el rendimiento del ordenador.

Además de indicarle a flymake con que herramienta queremos trabajar, tenemos que activarlo para los buffers que nos interesen. Esto podemos hacerlo de varios modos:

  • Manual. Activando el modo menor de flymake. M-x flymake-mode
  • Que active el modo menor flymake cuando estemos en el modo python. Añadiendo al .emacs
    (add-hook 'python-mode-hook 'flymake-mode)
  • O que active el modo flymake en base a las extensiones de fichero que le hemos pasado anteriorme (flymake-allowed-file-name-masks)
    (add-hook 'find-file-hook 'flymake-find-file-hook)

Configurar flymake

Por defecto flymake ilumina (highlight) la línea de código donde se produce el error, empleando un color u otro en función de si es un error o un warning. Al dejar el ratón encima de la línea con el error (hover) nos muestra la descripción del error.

Para cambiar los colores que se emplean por defecto podemos emplear algo parecido a esto:
<br></br>'(flymake-errline ((((class color)) (:background "LightPink" :foreground "black"))))<br></br>'(flymake-warnline ((((class color)) (:background "LightBlue2" :foreground "black"))))<br></br>
Para que subraye en lugar de hacer highlight de la línea con el error:
<br></br>'(flymake-errline ((((class color)) (:underline "red"))))<br></br>'(flymake-warnline ((((class color)) (:underline "yellow")))))<br></br>

Para hacer que el fringe derecho se muestre un indicador de en que líneas hay errores podemos usar rfringe. Aunque yo no he sido capaz de hacerlo funcionar.

Mostrar la descripción del error en el minibuffer. Esto es imprescindible cuando se trabaja en modo -nw.
<br></br>(defun my-flymake-show-help ()<br></br>(when (get-char-property (point) 'flymake-overlay)<br></br>(let ((help (get-char-property (point) 'help-echo)))<br></br>(if help (message "%s" help)))))<br></br>(add-hook 'post-command-hook 'my-flymake-show-help)<br></br>
Aunque el código anterior a mi me funciona, para mostrar el error en el minibuffer se suele emplear el plugin flymake-cursor.

Moverse a través de los errores. Podemos emplear los comandos M-x flymake-goto-prev-error para ir al error anterior, o M-x flymake-goto-next-error para ir al siguiente. También podemos vincularlos a determinadas teclas:
<br></br>(global-set-key [TECLA] 'flymake-goto-prev-error)<br></br>(global-set-key [TECLA] 'flymake-goto-next-error)<br></br>
Links relacionados

Las raíces de la violencia

Mis lecturas de fin de semana comenzaban ayer con el artículo ¿Cuáles son los países más violentos del mundo? ¿Por qué?. El artículo no es demasiado científico pero abre una línea de debate interesante, y hay comentarios de calidad. Mi mayor crítica es hablar de violencia fijándose unicamente en la tasa de homicidios, cuando la violencia puede tener muchas otras formas.

El tema debe estar de moda porque hoy he podido leer un poco más sobre las raices de la violencia urbana en el blog de Duncan Green de Oxfam. Os aconsejo leerlo.

PD: Hace poco he estado en Honduras, y este comentario me ha llamado especialmente la atención, porque coincide con lo que percibí y lo que me transmitieron.

Herramientas de análisis de código estático en Python

Programar es fácil, y puede hacerse con el bloc de notas. Escribir buen código es bastante más complicado, por ello existen un montón de herramientas que pueden ayudarnos. Un tipo de herramientas que he empezado a usar (en python) ultimamente son las de análisis estático de código. Estas herramientas examinan tu código (sin ejecutarlo) en busca de ciertos patrones, alertando de «code smells», incroguencias de estilo, posibles bugs, código repetido e incluso dando consejos sobre rendimiento o encapsulamiento en algunos casos.

En python tenemos disponibles distintos analizadores de código, y es habitual ver preguntas sobre cual es mejor. Las cuatro herramientas de este tipo para python están actualizadas a las últimas versiones en los repositorios de ubuntu. Para instalarlas:

sudo apt-get install pyflakes pep8 pychecker pylint

Pyflakes

Pyflakes parece la más sencilla de las cuatro herramientas que he usado. Hace pocas comprobaciones del tipo, imports no usados, variables asignadas y no empleadas, …
No chequea el estilo, ni advierte sobre posibles bugs, aunque dicen que es de las más rápidas, por lo que es la que la gente suele usar como «chequeador de código automático» en IDEs como PyDev o emacs.

pep8

pep8 valida el estilo de nuestro código (de forma bastante rigurosa) contra el estándar de estilo PEP8 de Python. Puede ayudar a detectar «code smells», pero no chequea «errores». Comprueba cosas como que las líneas no tengan más de 80 caracteres, los nombres de variables tengan un determinado formato, …

Para chequear un fichero llega con hacer:
pep8 nombre_de_ficheros.py

Aunque habitualmente se lanza con más opciones para obtener más información:
pep8 --show-source --show-pep8 nombre_de_ficheros.py

Cuando lo lanzamos con –show-pep8 proporciona bastante información sobre la regla de estilo que estamos rompiendo por lo que resulta útil para ir interiorizándolas.

Pychecker

Pychecker es la más antigua pero ahora está algo parado. La última versión 0.8.19 es de enero de 2011 y la anterior del 2008. PyChecker si que es bastante potente en cuanto a la detección de posibles bugs o errores como el de usar una variable antes de asignales un valor, llamar a un método que no existe, … En general detecta bastantes de esos errores que se cometen en python (cuando no se usa un IDE que ya detecte estas cosas)
Parámetros interesantes.
–blacklist=unittest Este módulo de python saca algún error con pychecker, así que para evitar ruido le decimos que no lo chequee.

Pychecker tiene, imho, un problema gordo, y es que ejecuta el código para chequearlo, no es realmente una herramienta de análisis estático, por lo que su uso es más bien desaconsejable.

Pylint

Pylint es una especie de mezcla entre pep8 y pychecker puesto que hace análisis tanto del estilo del código como de posibles bugs. Tiene un montón de características, es extensible mediante plugins, …

El informe que proporciona sobre el código es bastante extenso, clasifica los errores por su gravedad, … Como tiene muchas opciones es conveniente echarle un ojo al tutorial y al manual aunque no hace falta para ver su potencial.

Los parámetros más interesantes de pyling son:

  • –reports=n Para que sólo nos saque los posibles errores y no imprima las estadísticas e informes. Puede ser útil ver el informe de vez en cuando, pero si vamos a pasar el chequeo muchas veces sólo mete ruido.
  • –include-ids=y Por defecto no nos muestra el código de error completo. Con esto hacemos que nos lo muestre para poder obtener más información sobre él si no lo entendemos (Esto lo haríamos con pyling –help-msg=ERROR_CODE)
  • –disable=C0111 Esto hace que no se chequeen, los errores C0111, que indican que todos los métodos deberían tener un docstring. Me gusta eliminarlos porque soy de los que piensan que «los comentarios apestan»

Para que la línea de comandos no se vuelva muy complicada estás opciones pueden indicarse en un fichero de configuración para que sean usadas por defecto

Como y cuando usarlas

Lo que me gusta de estas cuatro herramientas es que no hay excusa para no usarlas. Son realmente sencillas, rápidas, y ayudan a hacer un código más legible y mantenible.

Por ahora, para acostumbrarme a ellas, lo que hago es al inicio de cada sesión de trabajo paso las cuatro herramientas en el siguiente orden:

  1. pep8 –show-source –show-pep8 *.py
  2. pylint –reports=n –include-ids=y –disable=C0111 *.py
  3. pychecker –blacklist=unittest *.py
  4. pyflakes *.py

Lo hago así porque me gusta la información sobre el estilo que proporciona pep8, y tras solucionar los errores de pylint ni pychecker ni pyflakes me están proporcionando ayuda adicional así que es probable que pronto deje de usarlos. De hecho cuando me acostumbre a la guía de estilo de pep8 es probable que sólo use pylint.

Como el proyecto en el que la estoy probando apenas son 6 o 7 clases de alrededor de 200 líneas, está forma de trabajar me resulta cómoda y me permite aprender a usarlas, pero está claro que en otros contextos puede no ser lo más adecuado.

En el próximo artículo de esta serie hablaremos sobre como integrar estas herramientas en emacs, al estilo de las sugerencias de eclipse u otros IDE, y otras aproximaciones un poco más sofisticadas de como integrarlas en nuestro flujo de trabajo.

¡Prueba y cuéntame!

Actualización 20/Julio: He añadido algún enlace y desaconsejado el uso de pychecker por las razones que ya están incluídas en el propio artículo.

Actualizar la versión de Antroid de un HTC Tattoo (II parte)

Las consideraciones generales sobre como actualizar las puedes leer en la primera parte de este artículo.

Las principales instrucciones que yo he seguido han sido la de los propios desarrolladores de la ROM que he instalado. Lo cuento un poco más detallado. Deberías seguir las instrucciones de esa guía, lo que aquí escribo son más bien posibles problemas y es complementario a lo que allí pone.

Los pasos a seguir

  1. Instalar jdk y android sdk. El único componente que hace falta es «SDK Platform tools» que es lo que contiene el comando adb.
  2. Enciende el GPS. A veces no lo detecta si lo tienes apagado y deja de funcionar. Y recuerda que las operaciones que hagamos a partir de ahora con el teléfono deben hacerse con la opción «depuración» activada (En tu teléfono, ajustes -> aplicaciones -> desarrollo)

  3. Rootear el dispositivo. Con el sistema proporcionado con Cyanogenmod yo conseguí acceso de Root (es cuando el prompt se convierte en #) pero no conseguí instalar el comando «su» para poder convertirse en root de forma sencilla. Así que cada vez que necesitaba acceso de root (cuando en los tutoriales se menciona usar «su«, tenía que ejecutar los comandos que se indican en el punto 5 y 6 de la parte de rooting). Un par de avisos:

  4. Si parece que se queda colgado pulsa intro para ver si aparece el prompt

  5. Si no consegues hacerlo, habilita la opción de instalar software desde fuentes no fiables y prueba a instalar alguna aplicación como UniversalAndroot. Recuerda que puedes instalar aplicaciones con adb usando adb install aplicación.apk

  6. Haz copia de seguridad con una aplicación como Titanium Backup o Mybackup … instalables desde el Market.

  7. Instala el recovery. A mi la versión de ClockModRecovery que está enlazada en las instrucciones me dió problemas. Descargué otra versión distinta de algún sitio que no recuerdo, y al que llegué buscando el error que me daba al intentar instalarlo.
  8. Apaga el teléfono y vuelve a encenderlo en modo recovery: botón de encendido + botón teléfono (verde/descolgar) + botón casa (home)
  9. Ve a la opción de «backup and restore» y haz un backup. Dejará en un directorio de la SD clockwordmod/backup/fecha una copia de seguridad de tu ROM actual y tus datos. Enciende el teléfono en modo normal y copia esa carpeta al pc.
  10. Llegamos al punto de no retorno. Si todavía quieres segir, enciende en modo Recovery y ejecuta las siguientes acciones:
  11. Wipe de datos
  12. Wipe de caché
  13. Wipe de Dalvik Caché (en «Advanced»)
  14. Format / System (en «mounts and storage)

  15. Factory Reset

  16. Sube al teléfono la ROM y las google apps. Como ROM yo emplee un nightly build con buenas críticas en los foros. Recuerda que puedes subirlas a la SD del teléfono con adb push <nombre_de_fichero> /sdcard.

  17. Enciende en modo recovery y en instalar zip escoge primero la rom y luego las google apps. Escoge reboot y cruza los dedos. La primera vez a mi me tardó en arrancar unos 3 o 4 minutos así que paciencia. Comprueba que todo funciona, GPS, Wifi, llamar etc … y listo. Acuerdate de configurar la red preferida, el punto de acceso, …

En caso de problemas con la batería

Espera a haber hecho un par de recargas completas. Si tras eso sigue habiendo problemas:

  1. Cargala al 100% y déjala todavía un rato más
  2. Sin desconectar el teléfono se enciende en modo recovery
  3. Se hace un wipe de la batería
  4. Apágalo y desconectalo
  5. Enciende el teléfono, y no lo apagues ni lo reinicies hasta que la batería se descargue totalmente por si sóla

Por otro lado, la ROM de Cyanogen viene con un launcher llamado ADW Launcher. Alguna gente opina que el que menos batería gasta es «Launcher Pro». Pero esto parece ser más bien para gustos.

Y una cosa que no me ha quedado clara es si la ROM de Cyanogen por defecto hace overclock del procesador, es decir como si hiciera girar más rápido al reloj que marca al ritmo que debe funcionar el procesado (que no tiene nada que ver con la hora). Esto gasta batería y puede controlarse con una aplicación llamada SetUP. Si bajas la frecuencia el teléfono será menos responsivo pero disminuirá el consumo de batería.

El resultado

[ ![17032012027](https://conocimientoabierto.es/wp-content/blogs.dir/16/files/galerias/enelblog/cache/17032012027.jpg-nggid0216-ngg0dyn-320x240x100-00f0w010c010r110f110r010t010.jpg "17032012027") ](https://conocimientoabierto.es/wp-content/blogs.dir/16/files/galerias/enelblog/17032012027.jpg)