Alberto Paparelli: PyCon-Ar 2014

Paso otra PyCon en Argentina, la sexta. Esta vez fue en Rafaela, Santa Fe.

Llegamos el Jueves a la tarde, por lo que ese día solo participe del sprint de la nueva web de pyar. Hice unos commits, pero no hubo mucho tiempo como para poder aportar mas.

El Viernes y Jueves fueron de charlas. Entre las que más me gustaron estan:

  • Tu propio cliente de Torrent streaming en Python (Por Felipe Lerena y GiLgAmEzH)
  • Django Security quick-wins (Por Andrés Riancho)
  • Prediciendo el mundial con inteligencia artificial (Por Juan Pedro Fisanotti)
  • Trabajando de forma asíncronica en Django/Python (Por Martín Alderete)
Foto grupal PyCon-AR 2014

De las charlas relámpago, me gusto mucho el cuento de Juanjo Conti, que me hizo acordar mucho al estilo de Hernán Casciari.

Con respecto al lugar (Rafaela), es lindo, aunque hay muy poco para hacer y recorrer.

Hernán Grecco: Pint 0.6: faster and with better non-multiplicative units support

I have released version 0.6 of Pint, a Python units library.

Pint is Python package to define, operate and manipulate physical quantities: the product of a numerical value and a unit of measurement. It allows arithmetic operations between them and conversions from and to different units.

It provides a comprehensive and extensive list of physical units, prefixes and constants defined in a standalone text file. The registry can parse prefixed and pluralized forms of units resulting in a much shorter and maintainable unit definition list.

It also provides great NumPy integration without monkey patching or importing a particular module, with implicit unit conversion and an emphasis on correctness.

What's new

The largest change landed in the way Pint handles offset units such as temperatures. It now provides a much better behavior that is both correct and useful. It deals properly with differences of temperatures, providing useful error messages when the requested operation is ambiguous.

There were many bug fixes and other internal changes. Thanks to some optimizations and aggressive caching, Pint continues to get faster in each release. We have also improved the quality of some error messages and parts of the code, and the test coverage is above 90%

There a lot of other improvements, you can look at the full list of changes.

Thanks to the people that contributed bug reports, suggestions and patches since 0.5. In particular to Matthieu Dartiailh, Ryan Kingsbury, Joel Mohler, Virgil Dupras, Jonas Olson, John David Reaver and Peter Grayson. A big thanks should be given to David Linke who did an awesome work with offset units (Please let me know if I am forgetting someone!)

Interested? Install it and give it a try!

Submit your bug reports, comments and suggestions in the Issue Tracker. There are already some ideas for version 0.7. Check them out, comment and add yours.

Read the docs: https://pint.readthedocs.org/
or fork the code: https://github.com/hgrecco/pint

Marcelo Fernández: Pwning hardware

El video dura media hora, pero a mí me gustó muchísimo, aprendí mucho. Mikah Scott es una genia, y se propone investigar cómo customizar el firmware de una lectora/grabadora de CD/DVD/Blu-Ray, para dominarlo por completo, empezando por el microcontrolador ARM que posee. Por ejemplo, moviendo el láser en la posición que uno quiera y dispararlo. Habla un excelente y puntilloso inglés, así que se le entiende palabra por palabra, sugiero que lo vean incluso para practicar su inglés técnico.

Es muy interesante cómo usa Photoshop para visualizar el contenido de un firmware (?!??!?! ¡nunca se me hubiera ocurrido!), y cómo usa IDA (este sí es más lógico) para interpretar el código binario.

Además, usa vusb-analyzer en Ubuntu para visualizar el tráfico USB dumpeado con usbmon o similares, por ejemplo snifeado de una máquina virtual.

Por último, usa iPython para hacer que el ARM y el resto de los chips con los que interactúa (mt1939, dsp) haga lo que uno quiera (todavía está en avance).

Es increíble cómo en el ámbito de seguridad se usa Python (lo confirmé en la Ekoparty en estos días).

Insisto, se aprende muchísimo viendo este tipo de videos: herramientas, técnicas, trucos y fundamentalmente cómo abordar estos desafíos.

Saludos

Hernán Grecco: PyVISA command-line utilities

PyVISA is a Python frontend for the VISA library that enables controlling all kinds of measurement equipment through GPIB, RS232, USB and Ethernet among others interfaces.

If you are following the development of PyVISA you might have seen that we have recently made the visa module executable to provide a few useful utilities. To try this, you need to update to the latest PyVISA:

$ pip install -U https://github.com/hgrecco/pyvisa/zipball/master

First, we now provide a simpler way to get debug information:

$ python -m visa info
Machine Details:
   Platform ID:    Darwin-10.8.0-x86_64-i386-32bit
   Processor:      i386

Python:
   Implementation: CPython
   Executable:     /Users/grecco/envs/lantz/bin/python
   Version:        3.2.3
   Compiler:       GCC 4.2.1 (Apple Inc. build 5666) (dot 3)
   Bits:           32bit
   Build:          Apr 10 2012 11:25:50 (#v3.2.3:3d0686d90f55)
   Unicode:        UCS2

PyVISA Version: 1.6.1

Backends:
   ni:
      Version: 1.6.1 (bundled with PyVISA)
      #1: /Library/Frameworks/visa.framework/visa:
         found by: auto
         bitness: 32
         Vendor: National Instruments
         Impl. Version: 5243392
         Spec. Version: 5243136
   py:
      Version: 0.1.dev0
      ASRL INSTR: Available via PySerial (10.8.0)
      TCPIP INSTR: Available
      USB INSTR: Available via PyUSB (1.0.0rc1). Backend: libusb0


Notice also that more useful information is given, including details about the different backends (in this case ni and py).

Another utility is the VISA shell which was taken from the Lantz project. It provides a way to list, open and query devices. It also allows you to get (and in the near future set) attributes. The shell has in-built help, autocomplete and

$ python -m visa shell
Welcome to the VISA shell. Type help or ? to list commands.

(visa) list
( 0) ASRL2::INSTR
( 1) ASRL1::INSTR
(visa) open ASRL1::INSTR
ASRL1::INSTR has been opened.
You can talk to the device using "write", "read" or "query".
The default end of message is added to each message
(open) attr
+-----------------------------+------------+----------------------------+-------------------------------------+
|          VISA name          |  Constant  |        Python name         |                 val                 |
+-----------------------------+------------+----------------------------+-------------------------------------+
| VI_ATTR_ASRL_ALLOW_TRANSMIT | 1073676734 |       allow_transmit       |                  1                  |
|    VI_ATTR_ASRL_AVAIL_NUM   | 1073676460 |      bytes_in_buffer       |                  0                  |
|      VI_ATTR_ASRL_BAUD      | 1073676321 |         baud_rate          |                 9600                |
|    VI_ATTR_ASRL_BREAK_LEN   | 1073676733 |        break_length        |                 250                 |
|   VI_ATTR_ASRL_BREAK_STATE  | 1073676732 |        break_state         |                  0                  |
|    VI_ATTR_ASRL_CONNECTED   | 1073676731 |                            |          VI_ERROR_NSUP_ATTR         |
|    VI_ATTR_ASRL_CTS_STATE   | 1073676462 |                            |                  0                  |
|    VI_ATTR_ASRL_DATA_BITS   | 1073676322 |         data_bits          |                  8                  |
|    VI_ATTR_ASRL_DCD_STATE   | 1073676463 |                            |                  0                  |
|  VI_ATTR_ASRL_DISCARD_NULL  | 1073676464 |        discard_null        |                  0                  |
|    VI_ATTR_ASRL_DSR_STATE   | 1073676465 |                            |                  0                  |
|    VI_ATTR_ASRL_DTR_STATE   | 1073676466 |                            |                  1                  |
|     VI_ATTR_ASRL_END_IN     | 1073676467 |         end_input          |                  2                  |
|     VI_ATTR_ASRL_END_OUT    | 1073676468 |                            |                  0                  |
|   VI_ATTR_ASRL_FLOW_CNTRL   | 1073676325 |                            |                  0                  |
|     VI_ATTR_ASRL_PARITY     | 1073676323 |           parity           |                  0                  |
|  VI_ATTR_ASRL_REPLACE_CHAR  | 1073676478 |        replace_char        |                  0                  |
|    VI_ATTR_ASRL_RI_STATE    | 1073676479 |                            |                  0                  |
|    VI_ATTR_ASRL_RTS_STATE   | 1073676480 |                            |                  1                  |
|    VI_ATTR_ASRL_STOP_BITS   | 1073676324 |         stop_bits          |                  10                 |
|    VI_ATTR_ASRL_WIRE_MODE   | 1073676735 |                            |                 128                 |
|    VI_ATTR_ASRL_XOFF_CHAR   | 1073676482 |         xoff_char          |                  19                 |
|    VI_ATTR_ASRL_XON_CHAR    | 1073676481 |          xon_char          |                  17                 |
|     VI_ATTR_DMA_ALLOW_EN    | 1073676318 |         allow_dma          |                  0                  |
|    VI_ATTR_FILE_APPEND_EN   | 1073676690 |                            |                  0                  |
|    VI_ATTR_INTF_INST_NAME   | 3221160169 |                            | ASRL1  (/dev/cu.Bluetooth-PDA-Sync) |
|       VI_ATTR_INTF_NUM      | 1073676662 |      interface_number      |                  1                  |
|      VI_ATTR_INTF_TYPE      | 1073676657 |                            |                  4                  |
|       VI_ATTR_IO_PROT       | 1073676316 |        io_protocol         |                  1                  |
|   VI_ATTR_MAX_QUEUE_LENGTH  | 1073676293 |                            |                  50                 |
|   VI_ATTR_RD_BUF_OPER_MODE  | 1073676330 |                            |                  3                  |
|     VI_ATTR_RD_BUF_SIZE     | 1073676331 |                            |                 4096                |
|      VI_ATTR_RM_SESSION     | 1073676484 |                            |               3160976               |
|      VI_ATTR_RSRC_CLASS     | 3221159937 |       resource_class       |                INSTR                |
|  VI_ATTR_RSRC_IMPL_VERSION  | 1073676291 |   implementation_version   |               5243392               |
|   VI_ATTR_RSRC_LOCK_STATE   | 1073676292 |         lock_state         |                  0                  |
|     VI_ATTR_RSRC_MANF_ID    | 1073676661 |                            |                 4086                |
|    VI_ATTR_RSRC_MANF_NAME   | 3221160308 | resource_manufacturer_name |         National Instruments        |
|      VI_ATTR_RSRC_NAME      | 3221159938 |       resource_name        |             ASRL1::INSTR            |
|  VI_ATTR_RSRC_SPEC_VERSION  | 1073676656 |        spec_version        |               5243136               |
|     VI_ATTR_SEND_END_EN     | 1073676310 |          send_end          |                  1                  |
|   VI_ATTR_SUPPRESS_END_EN   | 1073676342 |                            |                  0                  |
|       VI_ATTR_TERMCHAR      | 1073676312 |                            |                  10                 |
|     VI_ATTR_TERMCHAR_EN     | 1073676344 |                            |                  0                  |
|      VI_ATTR_TMO_VALUE      | 1073676314 |                            |                 2000                |
|       VI_ATTR_TRIG_ID       | 1073676663 |                            |                  -1                 |
|   VI_ATTR_WR_BUF_OPER_MODE  | 1073676333 |                            |                  2                  |
|     VI_ATTR_WR_BUF_SIZE     | 1073676334 |                            |                 4096                |
+-----------------------------+------------+----------------------------+-------------------------------------+
(open) close
The resource has been closed.



Again, this release is only possible thanks to the contribution of a lot of people that contributed bug reports, testing and code. Thanks to everybody!

Submit your bug reports, comments and suggestions in the Issue Tracker. We will address them promptly.

Read the development docs: https://pyvisa.readthedocs.org/en/master/
or fork the code: https:/https://github.com/hgrecco/pyvisa/

Gustavo Campanelli: Como recuperé 20 GB de mi disco rígido

Recientemente vi que el juego DC Universe Online se podía jugar gratuitamente, así que decidí darle una oportunidad y bajarlo. Luego de 3 días de descarga (a bajas velocidades mientras jugaba otras cosas, a altas velocidades de noche) lo tuve disponible. Jugué unas 7 horas. y debo decir que me resultaron bastante entretenidas. El comienzo, el escape de la nave de Brainiac, está muy bien diseñado

Marcos Dione: testing-qt4-applicationswith-slots-and-signals

A few days ago someone said something[1] that reminded me about my audio player, which I had abandoned for more than a year already. The reason was mostly that the two Phonon backends, VLC and gstreamer, for some reason or other couldn't play the files I had without any gaps between songs.

To be honest, the first bug end up being me not properly encoding the filenames. If you first URL-encoded the filename and then built a Q/KURL with that, then it's all fine. It took me more than 12 months and a few rereads of the thread to realize it. Fixes apart, it seems that the bug still exists for other instances of gstreamer errors, so we're not out of the woods. In any case, I switched to the VLC backend and it seems that now is able to fire the aboutToFinnish() signal properly, so for the moment I'm using that.

All that is fine, but that's not what I wanted to talk about in this post. Given that this project largely precedes my interest on testing, it has no testing at all. Most of the project is straightforward enough to almost no need any, but there's a critic part that would not suffer at all if it had any, namely the Collections handling, including passing files from one to another and automatically updating new/removed Songs[2].

So after fixing the bug mentioned above I tried to figure out the current state of affaires regarding Collections, and boy, they're in bad shape. The code was locally modified, never commited, deactivating any notifications of filesystem changes (new or removed files), and other code I can't really understand the purpose of.

Because if this last detail is that I decided to start testing three classes: Collection, which handles a set a Songs with a common root directory; CollectionAggregator, which handles a set of collections and should coordinate moving a Song from one Collection to another; and CollectionIndexer, which scans from a Collection's root dir to find Songs.

All went fine while I tested the first class, Collection. There was a tricky part where I had to setup a QApplication in order to make signals work. The problems began when I started testing CollectionIndexer. Tests started blocking endlessly, signals stopped being either emited or firing the connected slots, life was bad.

I tried to search the available documentation and mailing lists for a hint about the problem, but besides a quite complex example that didn't seem to properly converge to anything useful, I was mostly on my own.

This morning I got my eureka moment: I noticed that if I executed each test class by itself, it worked, but both at the same time blocked and never finished. Then I remembered something said in QApplication's documentation:

For any GUI application using Qt, there is precisely one QApplication object, no matter whether the application has 0, 1, 2 or more windows at any given time.

That was it: I was creating the application, first in the setUp() method, then as a class attribute, but I had one test class per class to test, each in its own file. Somehow this last fact lead me to think that somehow they were executed in separate processes, which is not true. Luckily, even with this limitation, there's none on the amount of times you can exec_() and quit() the same instance, so that's what I did: I created only one instance and reused it everywhere. I was already doing that for each test method, but again, somehow having several files mislead me to think they were isolated from each other.

So now all my unit tests work without mysteriously blocking forever. Now I just hope I can keep riding the success wave and bring satyr into good shape. A new release wouldn't hurt.


[1] No matter how much I try, I can't get any vaguer.

[2] Ok, maybe the Player/Playlist combo wouldn't hurt to have UTs either.


satyr pykde python

Hernán Grecco: Communicating with instruments using PyVISA but without NI-VISA

PyVISA is a Python frontend for the VISA library that enables controlling all kinds of measurement equipment through GPIB, RS232, USB and Ethernet among others interfaces.

Starting form version 1.6, PyVISA allows to use different backends. The cool thing is that your code remains the same, except the line in which you instantiate the resource manager (which tells which backend to use).

A few days ago I blogged about one of such alternative backends called PyVISA-sim which allows your to mock the presence of instruments (in cased that you missed the announcement, is here). Today I am making public a second backend.
 
Until now, talking to instruments via PyVISA required that you had National Instruments VISA library installed in your system. This works most of the time, for most people. But NI-VISA is a proprietary library that only works on certain systems. That is when PyVISA-py jumps in. It is an implementation of message based communication (Serial/USB/Ethernet) using Python and some well developed, easy to deploy and cross platform libraries (PySerial/PyUSB/Python Standard Library). In the near future it will also use linux-gpib to provide access to GPIB instruments in linux.

Cool, right? PyVISA without NI-VISA.

It actually started with an issue in the PyVISA tracker. A user wanted to use the LibreVISA library: an open source alternative to NI-VISA. While in principle this could work, it does not as LibreVISA is still incomplete. That is when it became obvious ... why not implementing parts of the VISA library in Python + friends? It would be open source, should be much easier to hack and compatible with PyVISA.

PyVISA-py is still young. Some very basic functionality is there but there still things to be done in order to implement all VISA features for message based sessions. But you can give it a try and provide feedback and why not code:

Just install (or upgrade) PyVISA 1.6 which is currently only available from GitHub:

$ pip install -U pyvisa

And then install:

$ pip install -U https://github.com/hgrecco/pyvisa-py/zipball/master

and then just instantiate your ResourceManager

import visa
rm = visa.ResourceManager('@py')

Notice that the rest of your code will be EXACTLY the same.

Remember that this is an early preview. We need your help to get it to the ready. Submit your bug reports, comments and suggestions in the Issue Tracker. We will address them promptly.

Or fork the code: https://github.com/hgrecco/pyvisa-py/

Joaquin Sorianello: Pixels de colores.

Desde que tengo memoria, pintar cosas con colores me costó muchísimo.

En la escuela primaria, por ejemplo, mis cuadernos tenian dibujos en lápiz negro, y grisados. Mi abuelo dibujaba así y lograba efectos buenísimos.

Para mi los lápices de colores se transformaban en bestias indomables que desparramaban color sin llegar a gustarme.

Cuando empecé a programar, siempre me escudé en "Yo hago la lógica, que otro le ponga colores". En fin, años de traumas por no poder combinar dos colores o mas.

Hace un par de años, en una de las visitas a mi genial sobrina Catalina, mis tios le mandaron conmigo una caja de acuarelas, y yo le llevaba libros de Oliver Jeffers.

Fue asombroso.

Probablemente tendría que escribir un post entero sobre como  el hacer actividades en las que nos sentimos inseguros, junto con niños, puede cambiar nuestras perspectivas.

El resultado, montones de dibujos "en colaboración" con mi sobrina,  analizamos juntos los dibujos de Jeffers y tratamos de darnos cuenta como lograba los efectos.

En ese momento, me di cuenta que necesitaba volver a dibujar y mejorar mi tema con los colores.

Miré videos, lei tutoriales sobre teoria del color y nada parecia mejorar.

Entonces mi primo Nahuel, me recomendó una charla, que me hizo cambiar mucho mi forma de ver las cosas:


En resumen, si no van a ver el video completo:

Dibujar todos los días, analizar que nos gusta de las cosas que nos gustan, copiar y transformar.

Una de esas cosas que hice fue mi portada para twitter usando pixeles grandotes. Para eso usé inkscape, y fue bastante engorroso.



Terminada la portada, me animé a hacer un patron para usar de fondo, el resultado... triste...

Es difícil hacer patrones repetitivos, sin que "el atomo" que se repite sea demasiado obvio.

Por eso, luego de escribir toneladas de javascript para el proyecto en el que estoy laburando, decidí tomarme un rato de programación lúdica, y armé pixium, una herramienta muy sencilla, para crear patrones.

El resultado, adictivo.

Como conclusión: dibujar y programar son cosas parecidas, ambas implican creatividad, y la mejor manera de estimularla es haciendo y analizando. Eso, creo, es fundamental para aprender.

Marcos Dione: virtualbox-could-not-find-xorg-or-xfree86

At work we have Windows workstations, but we develop for Linux (don't ask; in my previous mission in another MegaCorp we had a similar setup for admining Linux servers...). We have access to devel machines via ssh and Samba, but the setup is laughable. I won't go too much into details because it's embarrassing and because I signed some kind of NDA somewhere.

Thing is, I setup a VM with VirtualBox in my workstation, installing a barebones Debian Sid. To have better integration with the Windows host I decided to install the VBox Linux Additions, but for some reason it was not setting up the video side of it. The error message is the one from the title:

Could not find X.org or XFree86 on the guest system. The X Window drivers will not be installed.

Thanks to this post I managed to quickly find out the reason. The step that actually tests and installs the x.org drivers is called like this:

/etc/init.d/vboxadd-x11 setup

If you run it with sh -x you will find out that it actually tests two things: the existence of /usr/lib/xorg/modules, which you can either create or just install the xserver-xorg-video-vesa package, and it tries to run X, which you will find in the xserver-xorg package.

So, TL;DR version: Just install these two packages:

sudo apt-get install xserver-xorg-video-vesa xserver-xorg

Now all works.


sysadmin

Martín Gaitán: Travis-CI para compilar y deployar tu blog estático

Travis-CI es un servicio de integración continua, gratuito para proyectos de software libre. Pero son gente tan copada que no se enojan si en vez de una suite de tests, corremos, por ejemplo, Nikola para compilar este blog y publicarlo automáticamente.

El flujo es así:

  1. Escribimos un post en el branch "fuente" (En mi caso writing) y comiteamos. Esto puede hacerse desde la propia compu, o usar el editor de Github :D
http://i.snag.gy/U4hmv.jpg
  1. Travis detecta el commit en el branch, clona el repo, instala las dependencias y ejecuta un script que corre nikola build y lo necesario para pushear el resultado (por ejemplo, la carpeta output) al branch Github pages (en general gh-pages, master en mi caso)
  2. Listo: Nikola desde la nube. For free.

Permiso, soy el CI

¿Cómo hace Travis para pushear de vuelta al repo? Bueno, hay que darle permiso. Para eso, necesitamos crear un token . Con un token, se puede pushear a un repo via HTTPS sin que pida clave usando la url https://<token>@github.com/owner/repo.git.

Pero como el archivo para configurar Travis es público (y el token es información muy sensible), lo configuramos como una variable de entorno encriptada. Para eso necesitamos el utilitario (hecho en ruby) que provee la gente de Travis:

$ sudo apt-get install ruby1.9.1-dev build-essentials
$ sudo gem install travis

$ travis encrypt GH_TOKEN=your_token

el resultado lo ponemos en el yaml:

env:
  global:
    secure: dlAoq4D...

y con eso Travis tendrá una varible de entorno global llamada GH_TOKEN que podemos usarla en nuestro script.

Podés ver el .travis.yml y el script que compila y pushea de vuelta