Manuel Kaufmann (Humitos): We're hiring

   Publicado:

Me gustó la idea...

... vas a flicker.com, presionás Ctrl+U y ves este mensaje.

Al menos van a contratar a un programador que conocé el Ctrl+U ;)

<!--                 _
        . -  ` : `   '.' ``  .            - '` ` .
      ' ,gi$@$q  pggq   pggq .            ' pggq
     + j@@@P*\7  @@@@   @@@@         _    : @@@@ !  ._  , .  _  - .
  . .  @@@K      @@@@        ;  -` `_,_ ` . @@@@ ;/           ` _,,_ `
  ; pgg@@@@gggq  @@@@   @@@@ .' ,iS@@@@@Si  @@@@  .6@@@P' !!!! j!!!!7 ;
    @@@@@@@@@@@  @@@@   @@@@ ` j@@@P*"*+Y7  @@@@ .6@@@P   !!!!47*"*+;
  `_   @@@@      @@@@   @@@@  .@@@7  .   `  @@@@.6@@@P  ` !!!!;  .    '
    .  @@@@   '  @@@@   @@@@  :@@@!  !:     @@@@7@@@K  `; !!!!  '  ` '
       @@@@   .  @@@@   @@@@  `%@@@.     .  @@@@`7@@@b  . !!!!  :
    !  @@@@      @@@@   @@@@   \@@@$+,,+4b  @@@@ `7@@@b   !!!!
       @@@@   :  @@@@   @@@@    `7%S@@hX!P' @@@@  `7@@@b  !!!!  .
    :  """"      """"   """"  :.   `^"^`    """"   `""""" ''''
     ` -  .   .       _._    `                 _._        _  . -
             , ` ,glllllllllg,    `-: '    .~ . . . ~.  `
              ,jlllllllllllllllp,  .!'  .+. . . . . . .+. `.
           ` jllllllllllllllllllll  `  +. . . . . . . . .+  .
         .  jllllllllllllllllllllll   . . . . . . . . . . .
           .l@@@@@@@lllllllllllllll. j. . . . . . . :::::::l `
         ; ;@@@@@@@@@@@@@@@@@@@lllll :. . :::::::::::::::::: ;
           :l@@@@@@@@@@@@@@@@@@@@@l; ::::::::::::::::::::::;
         `  Y@@@@@@@@@@@@@@@@@@@@@P   :::::::::::::::::::::  '
          -  Y@@@@@@@@@@@@@@@@@@@P  .  :::::::::::::::::::  .
              `*@@@@@@@@@@@@@@@*` `  `  `:::::::::::::::`
             `.  `*%@@@@@@@%*`  .      `  `+:::::::::+`  '
                 .    ```   _ '          - .   ```     -
                    `  '                     `  '  `

     You're reading. We're hiring.
     https://flickr.com/jobs/
  -->

Juanjo Conti: Videos en la Feria del libro de Santa Fe 2014 (martes)

   Publicado:

Gonzalo Geller:

Elián del Mestre:

Guarriors:

Flor y Vale sobre el dibujo:

Clips:

Marcelo Fernández: Comparando costos de Amazon EC2 y Google Computing Engine

   Publicado:

Estuve mirando y por suerte son prácticamente similares las tablas disponibles en cada site (EC2 / GCE) y es relativamente sencillo compararlas [1][2].

Para sus Data Centers en USA, establecí las siguientes relaciones:

  • En las versiones de VMs “standard“, los precios son exactamente iguales, con configuraciones llamativamente similares.
  • En las versiones “high memory“, es más barato Google (la mitad), aunque Amazon te da el doble de CPUs por una VM con la misma cantidad de memoria.
    Ej: Google te da 4 CPUs / 26 GB de RAM y Amazon en cambio te da 8 CPUs para su configuración de 26 GB de RAM. Dado que estamos en “high memory“, igualé a cantidad de memoria disponible para luego decir “Google es la mitad de barato”.
  • En las versiones “large” (“high cpu” de Google), Amazon es un 15% más caro para igual cantidad de CPUs, pero te da el doble de memoria en sus VMs.

Observaciones:

  • Se desprende de lo anterior Amazon EC2 ofrece perfiles más simétricos que Google comparando la relación de cantidades de CPU/Memoria. Puede ser útil para algunas aplicaciones o no, ya que va obviamente asociado al costo.
  • Amazon tiene configuraciones con más CPUs ya que llega a 32 CPUs y más memoria también: 244 GB; Google llega a 16 CPUs y 104 GB de memoria.
  • No comparé tamaños de almacenamiento, asumo que no tiene tanta relevancia para nuestra aplicación (se disponen de varias decenas de GB en disco en ambos).
  • Amazon dice que te incluye discos de estado sólido (SSD). Google te cobra ambos (?) 0,04 USD por GB/mes el disco estándar, 0,325 USD GB/mes el SSD.
  • Fundamental para la región en la que vivo: Amazon tiene Data Center en San Pablo (Brasil), Google no; sólo sirve VMs desde USA, Europa y Asia/Pacífico.
  • Amazon tiene diferentes tipo de instancias, en este caso comparé las “Bajo demanda” aka “Dedicadas” (según el lugar que se mire en la documentación), que son las más caras. Las otras son tipo prepagas (“Instancias Reservadas”), donde según entiendo, uno abona un importe fijo y después usa X cantidad de tiempo y se descuenta del fijo.
    Hay otros tipos de instancias pero no se ajustan a nuestro uso (“Instancias Puntuales” y “Instancias optimizadas para EBS”). En este apartado, pareciera que Amazon tiene largamente muchas más ofertas y más desarrollo del negocio que Google.

Bonus Track: versus Linode.com

  • Linode tiene hasta 20 CPUs / 96 GB RAM máximo [3].
  • Linode es mucho más barato que ambos; es más simple su tabla de precios y más “1 a 1″ la distribución de CPUs / RAM (4GB / 4CPUs, 8 GB / 6 CPUs, y así hacia arriba), además de que da bastante más storage en SSD.
    Por ejemplo, 4 GB / 4 CPUs en Linode: USD 0,06/hora (USD 40/mes), mientras que en Amazon estamos en USD 0,28/hora por 15GB / 4 CPUs o USD 0,105/hora por 3,75GB / 2 CPUs. Eso sí, Linode está en USA (Newark/Atlanta/Dallas/Fremont), Europa (Londres) y Asia (Tokio), no en Sudamérica.
  • Comparando Linode contra GCE:
    • 1 Linode (2 GB de RAM/ 2 CPUs / 3 TB transfer / 48 GB SSD): U$S 20/mes.
    • 1 GCE (1,70 GB RAM / CPUs “shared” (?) / 48 GB SSD): U$S 33.29/mes (no dicen si hay límite de transferencia).
  • A Linode lo conocemos los que estamos “en la pomada”, y hay casos en donde suena mucho mejor “lo tengo repartido en la nube de Amazon/Google”, nobleza obliga.

[1] http://aws.amazon.com/es/ec2/purchasing-options/dedicated-instances/
[2] https://cloud.google.com/products/compute-engine/
[3] https://www.linode.com/pricing

¿Sugerencias, comentarios?

Saludos

Juanjo Conti: Videos en la Feria del libro de Santa Fe 2014 (1er domingo)

   Publicado:

Taller de creación de fanzines:

Sofía Storani leyendo:

Clips:

Juanjo Conti: Sobre la existencia de los fantasmas en Yerba #6

   Publicado:

El sábado en la Feria del Libro de Santa Fe se presentó el número 6 del fanzine Yerba. Como está dedicado a los Cazafantasmas, me pareció apropiado enviar este cuento.

Yerba 6

Juanjo Conti: Cómo un programador escribe una novela (video)

   Publicado:

Capturado el sábado 14 en la Feria del libro de Santa Fe. Versión en video de esta charla.

Juanjo Conti: Presentación de la novela Xolopes (video)

   Publicado:

Sábado 14 de septiembre de 2014. Feria del Libro de Santa Fe. Presentación de la novela Xolopes:

Gonzalo Martinez: Aprendiendo Erlang parte 6 Modulos III

   Publicado: Más acerca de módulos

Antes de movernos a profundizar nuestro conocimiento en relación a como escribir funciones y algunos fragmentos de código, pero antes tenemos un poco más de información que te será útil en el futuro.

Una de las primeras son los metadatos de los módulos. Los atributos de los módulos son metadatos que describen el módulo en si mismo. Donde podemos encontrar estos metadatos cuando no tenemos acceso al código fuente? Bueno, el compilador nos ayuda con esto: cuando compilamos un módulo, este toma la mayoría de los atributos y los almacena en una función llamada module_info/0 . Así pueden ver los metadatos de un módulo.

9> useless:module_info().
[{exports,[{add,2},
{hello,0},
{greet_and_add_two,1},
{module_info,0},
{module_info,1}]},
{imports,[]},
{attributes,[{vsn,[174839656007867314473085021121413256129]}]},
{compile,[{options,[]},
{version,"4.6.2"},
{time,{2009,9,9,22,15,50}},
{source,"/home/ferd/learn-you-some-erlang/useless.erl"}]}]
10> useless:module_info(attributes).
[{vsn,[174839656007867314473085021121413256129]}]
El snippet anterior además muestra la función module_info/1 que permite solicitar una pieza especifica de información.

Sintaxis en funciones

Coincidencia de patrones

Ahora tenemos la habilidad de almacenar y compilar código, podemos empezar a escribir funciones más avanzadas. La primera función que vamos a escribir necesita saludar de manera diferente según el genero.  En la mayoría de los lenguajes podrías escribir algo así.

function saludar(Genero, Nombre)
    if Genero == masculino then
        printf("Hola, Sr. %s!", Nombre)
    else if Genero == femenino then
        printf("Hola Sra. %s!", Nombre)
    else
        printf("Hola, %s!", Nombre)

Con coincidencia de patrones (pattern matching), erlang te ayuda a no escribir tanto código similar. La misma función en erlang se vería como esto.

saludar(masculino, Nombre) ->
    io:format("Hola, Sr. ~s!", [Nombre]);
saludar(femenino, Nombre) ->
    io:format("Hola, Sra. ~s!", [Nombre]);
saludar(_, Nombre) ->
    io:format("Hola, ~s!", [Nombre]).

Hay que adminit que la función de impresión por pantalla es un poco más fea en erlang que entro lenguaje pero ese no es el punto. La diferencia principal aquí es que nosotros usamos la coincidencia de patrones para definir las dos partes de una función se debe utilizar y ligas los valores al mismo tiempo. Aquí no se necesita primero ligar los valores y entonces compararlos.
En lugar de:

function(Args)
    if X then
        Expression
    else if Y then
        Expression
    else
        Expression

Nosotros escribimos:

function(X) ->
    Expression;
function(Y) ->
    Expression;
function(_) ->
    Expression.

De esta manera se obtiene los mismo resultados pero con un estilo más declarativo. Cada una de estas declaraciones de funciones es llamada clausula de función. Las clausulas de función deben ser separadas con punto y coma ";"

La coincidencia de patrones en las funciones puede ser más complejo y poderoso que eso. Tal vez recuerdas de capitulos anteriores donde usabamos coincidencia de patrones patrones para encontrar la cabeza y cola de una lista. Vamos a hacer esto.  Creamos un modulo llamado funciones.

-module(functions).
-compile(export_all).

La primera función que vamos a escribir es head/1, que actua exactamente como erlang:hd/1 que toma una lista como argumento y retorna su primer elemento. Los haremos con la ayuda del signo "|".

head([H|_])  -> H.

Si vos escribis functions:head([1,2,3,4]) en la terminal (una vez que el modulo sea compilado), puedes esperar que te retorne el valor 1. Consecuentemente para obtener el segundo elemento de la lista, puedes crear la siguiente función.

second([_,X|_]) -> X.

La lista será deconstruida por erlang en orden a hacer coincidir los patrones. Intentalo en la terminal.

1> c(functions).
{ok, functions}
2> functions.head([1,2,3,4]).
1
3> functions.second([1,2,3,4]).
2

esto podría ser repetido en la lista tanto como quitas, pero es impráctico para cientos de valores. Esto se puede resolver escribiendo funciones recursivas, aunque veremos como más adelante. Por ahora concentremonos más en la coincidencia de patrones. El concepto de variables libres y llenas nosotros los discutimos anteriormente, esto es así también para las funciones, podemos entonces comparar y conocer si dos parametros pasados a una función son lo mismo o no. Para esto, crearemos una función llamada same/2 que toma dos argumentos y dice si son identicos.

same(X,X) ->
    true;
save(_,_) ->
    false.

Y es así de simple.

Guardas, guardas.

Las guardas son clausulas adicionales que pueden ir en la cabecera de una función para hacer la coincidencia de patrones más expresiva. Como mencionamos antes la coincidencia de patrones está de alguna manera limitada ya que no puede expresar cosas como rangos de valores o cierto tipo de datos. Unos conceptos que no podemos representar serían los siguientes. Es este jugador de 12 años demasiado petizo para jugar con los profesionales? Es esta distincia demasiado larga para caminar sobre tus manos? Eres demasiado viejo o demasiado joven para manejar un auto?. No puedes responder esto simplemente con coincidencia de patrones. Se puede representar la pregunta sobre el manejo de un auto de la siguiente manera.

old_enough(0) -> false;
old_enough(1) -> false;
old_enough(2) -> false;
...
old_enough(14) -> false;
old_enough(15) -> false;
old_enough(_) -> true.

Pero esto es increiblemente impráctico. Puedes hacerlo si lo quieres, pero trabajarás solo en tu código por siempre. Si quieres eventualmente hacer amigos, entonces debes usar el modulo de guardas  así podremos escribir la pregunta sobre el manejo de la siguiente manera.

old_enough(X) when X >= 16 -> true;
old_enough(_) -> false.

y listo. Como puedes ver es mucho más limpio y corto. Notarás que la regla básica de una guarda es que debe retornar true cuando es correcta, la guarda puede fallar si retorna false o si lanza una excepción. Supongamos ahora que no queremos tener en cuenta a las personas que son mayores de 104 años. Entonces deberiamos cuidarnos de eso, pero como?, simplemente agregando una segunda guarda.

right_age(X) when X >= 16, X <= 104 ->
    true;
right_age(_) ->
    false.

La "," funciona como un "y tambien", y el punto y coma ";"  funciona como un "o sino"


http://learnyousomeerlang.com/modules#mode-about-modules

Facundo Batista: Causa y consecuencia, consecuencia y causa, quizás

   Publicado:


¿Cómo es que llegaste a leer esto? En algún momento apretaste un botón y la computadora se prendió. Luego hiciste un click y se abrió el navegador. Hiciste otro click o escribiste algo, y entraste a mi blog.

Esos son ejemplos de causas y consecuencias. Estamos muy acostumbrados a vivir en un mundo donde las causas y las consecuencias están firmemente atadas. Lo vemos todo así, aunque no estemos todo el tiempo razonándolo. Ejemplo: vemos una hoja en el piso. Sabemos que la hoja vino de un árbol, aunque no razonamos toda la secuencia: la hoja estaba en el árbol, la hoja se desprendió, fue cayendo y desplazándose por efecto de la gravedad y el aire, hasta que cayó donde la vemos.

Incluso, podríamos hacer el razonamiento al revés: vemos la hoja, está ahí porque cayó del árbol, cayó porque se desprendió, etc. En general, sin embargo no hacemos estos razonamientos de forma consciente.

Todo esto es común para vos, y no presenta mayor sorpresa, ¿cierto? Eso es porque estamos acostumbrados a la causa y consecuencia, forma parte de nuestra experiencia como humanos, es la forma en que nuestro cerebro interpreta todo lo que nos pasa. Desde que nacemos estamos expuestos a lo que nuestros sensores capturan (ojos, oídos, piel, etc), y formamos una imagen de la realidad en base a esa información.

Pero esa realidad que nosotros percibimos, y que nos es común (en el sentido en que la vivimos siempre, y en que es la misma que viven el resto de los humanos), es sólo parte de todo lo que realmente existe. Es decir, sólo interpretamos parte de la realidad, sentimos sólo una parte de lo que realmente existe. Y todo aquello que está fuera de nuestra experiencia es muy difícil de entender, porque nuestro cerebro no está acostumbrado a procesarlo.

Una de esas cosas es el tiempo. Y no estoy hablando de si llueve o mañana va a ser un día soleado (o sea, el clima) sino el tiempo como lo que pasa entre el "antes", el "ahora" y el "después". Nosotros creemos que entendemos qué pasa con el tiempo, porque en general estamos expuestos a siempre lo mismo con respecto a esa variable física. Siempre sentimos parte de la realidad, aquella en la que la flecha del tiempo es reversible. Por eso a partir de la situación del ahora se puede deducir la situación del después. O incluso sabiendo el estado actual podemos saber como estaba el sistema antes.

Pongamos un ejemplo para entenderlo mejor: soltemos una pelota en el aire...

La pelota, antes de soltarla

En el momento de soltar la pelota, la misma está quieta y a una altura determinada. Si yo te pregunto, qué pasa luego de soltar la pelota, me contestarías fácilmente. Obviamente, momentos después, la pelota está más abajo, y cayendo a una velocidad determinada...

La pelota, un rato después

También, si en lugar de mostrarte las dos imágenes al mismo tiempo, te muestro la segunda, te podés imaginar la primera. Es como en el caso de ver la hoja del árbol en el piso, sabés que antes estaba en una rama.

Implícito en todo esto está la reversibilidad del tiempo. Viendo la primera imagen (que está sacada en "tiempo cero") podemos imaginar el avance del tiempo y predecir que va a pasar después (con tiempo t‚, obviamente mayor que cero) , o viendo la segunda imagen podemos predecir que pasaría si el tiempo retrocediese e imaginar la primera imagen.

Lo vemos incluso en las ecuaciones que describen este modelo simple. Vayamos por ejemplo a las posiciones... la ecuación para esto es:

  e = ½.a.t²

Eso es: el espacio recorrido (h‚ - h, en el dibujo) es la mitad de la aceleración multiplicada por el tiempo que pasó al cuadrado. Si entre la primera y segunda imagen pasaron 2 segundos, siendo la aceleración 9.81m/s² (más o menos, acá en la Tierra), tenemos que el espacio es 19.62m. O sea, viendo la primera imagen podemos deducir que 2 segundos después la pelota va a estar casi 20 metros más abajo... y si vemos la segunda imagen, podemos deducir que 2 segundos antes (o sea, usando t=-2s en la ecuación) la pelota estaba esa distancia más arriba (el espacio lo recorremos en la dirección contraria, porque el resultado de la ecuación nos dio negativo).

Más allá de la complejidad matemática (?) todo esto que te estoy contando no te parece muy loco, ¿no? No. Pero ojo... no todo es tan simple en esta vida (bah, en este Universo).

Y no es tan simple, porque esto de poder ir para adelante y para atrás en el tiempo ,en nuestra mente, en nuestros razonamientos, ¡sorpresivamente no siempre se cumple!

Vayamos con otro ejemplo sencillo (aunque un poco más difícil de construir)... mirá el siguiente dibujo.

Foton loco, viaje de ida

Eso es una lamparita que tira de a un fotón (la mínima unidad de luz, su partícula elemental), una superficie semiespejada (la explico abajo), y un detector de fotones (que nos va a decir si el fotón llegó ahí).

La superficie semiespejada es un instrumento óptico que tiene el siguiente efecto: deja pasar la mitad de la luz, y la otra mitad la refleja. O sea, si lo iluminamos con un millón de fotones, la mitad sigue derecho, y la otra mitad rebota. En el caso de nuestro experimento, que le tiramos de a un sólo fotón, podemos decir que ese fotón tiene la mitad de chance de ser reflejado, y la mitad de chance de seguir derecho. [0]

Entonces, veamos qué pasa cuando la lamparita emite un fotón. Este va derechito hasta el espejo (recorrido A-B), y como dijimos puede seguir su camino o reflejarse e irse para la pared. Podemos decir que el recorrido A-B-C tiene un 50% de probabilidad de que suceda, y el recorrido A-B-D tiene la otra mitad. Piénsenlo como las dos fases del ejemplo anterior, el de la pelota: viendo el fotón saliendo de la lamparita como estado inicial, se pueden imaginar que va a pasar después (o sea, avanzando en el tiempo): que el fotón pegue en el detector, o que pegue en la pared.

Pero ahora hagamos la pregunta inversa: arranquemos de la segunda imagen, y tratemos de deducir la primera. O sea, tratemos de imaginar qué pasó antes (retrocediendo en el tiempo), arrancando nuestra visualización desde el fotón impactando en el detector. Para eso voy dibujo el mismo experimento, pero con otros recorridos...

Fotón loco, viaje de vuelta

¿Cómo se entiende este nuevo dibujo? Como decía, tenemos que pensar para atrás. Si nosotros sabemos que el detector recibió un fotón, la trayectoria B-C seguro se cumplió; entonces, al punto B del semiespejo el fotón llego de uno de dos lados posibles: o de la lamparita en A (atravesando el semiespejo), o desde un nuevo punto D (reflejándose en el semiespejo).

Acá me dirás que le estoy pifiando conceptualmente... ¿cómo puede ser que el fotón salga desde el punto D, que arranque desde una pared? Pues claro, ¡el fotón no puede venir nunca de ahí! Eso hace que la trayectoria E-B-C no sea realmente posible. En otras palabras, el fotón salió sí o sí de la lamparita: la trayectoria A-B-C se recorrió seguro (un 100% de probabilidad).

No te sientas frustrada/o si tenés que leer dos o tres veces la explicación para entender que pasa, es bastante avanzado a nivel de física. Yo, la primera vez, lo tuve que leer como cinco veces ;). Una de las razones por la que cuesta entenderlo, y hasta aceptarlo es que, justamente, todo eso está por afuera de lo que nosotros sentimos del universo, no forma parte de nuestra experiencia.

En fin, resumiendo los dos análisis: si hacemos que el tiempo se desarrolle para adelante, arrancando con el fotón desde A, vemos que puede recorrer dos trayectorias, A-B-C o A-B-D, con un 50% de chances cada una. Pero si hacemos que el tiempo se desarrolle para atrás, arrancando con el fotón desde C, tenemos que sólo pudo recorrer un camino: A-B-C.

¡Esta es una muestra de que el fotón atravesando el semiespejo no se comporta de una forma reversible en el tiempo! El tener dos posibles recorridos cuando hacemos correr el tiempo para adelante, y uno solo cuando lo hacemos recorrer para atrás, es totalmente distinto a lo que veíamos en el primer experimento, y totalmente distinto a la forma en que vemos normalmente a nuestro entorno, a la forma en que experimentamos el Universo.

La razón de este comportamiento se explica en las bases de la mecánica cuántica, donde se ve y entiende que hay todo un modelo que explica nuestro Universo con el tiempo reversible, pero hay toda una parte donde el tiempo no lo es. O sea, hay toda una rama de la física donde en las ecuaciones no podemos cambiarle alegremente el signo a t.

Respirá aliviada/o, no voy a meterme en toda esa explicación ;) [1]. Pero lo que te quería mostrar es que ahí afuera, aunque no lo veamos, aunque no forme parte de nuestra experiencia como humanos, hay todo un Universo al que sólo podemos acceder con el poder de nuestros cerebros y su capacidad de pensamiento abstracto. Es una herramienta maravillosa, ¡la tenemos que entrenar más y mejor!


[0] Para usar terminología adecuada, tenemos que decir que hay una amplitud de uno sobre raíz cuadrada de dos de que el fotón esté en un lado y la misma amplitud de que esté en el otro... eso es hablando de distribución de amplitudes con respecto a las posiciones... el módulo del cuadrado de eso nos da la probabilidad de que el fotón esté en un punto o el otro, que es .5 en cada caso.

[1] Pero si te interesa, hay un libro que es GENIAL y que habla de esto en tres o cuatro páginas del medio millar que tiene: The Emperor's New Mind, de Roger Penrose

Hernán Grecco: PyVISA 1.6 brings comprehensive resources classes, thread-safety and more

   Publicado:

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

PyVISA 1.6 release is close and it brings several new nice things. One of the most visible improvements is the addition of a comprehensive set of resources classes, each mapping to a one of the 13 types of resources. Each class implements the methods and attributes that the specific session can handle, providing a Pythonic way to interact with the device (See here). This has allowed us to implement higher level functions such as the group execute trigger in the GPIB Interface.

PyVISA 1.6 brings a much better way to query a device for values, providing a comprehensive API to convert back and from ASCII and binary blocks. An API to write values to a device has been added (See here).

PyVISA 1.6 is thread-safe. While the VISA library has always been thread-safe, PyVISA was not. We have refactored the code removing several global variables that were used to handle state and tweaked the API accordingly.

PyVISA 1.6 continues on the road started with 1.5 to improve debugging, usability and reporting. The quality and density of logging messages have been improved as well as the information provided with the error messages. Python 3.4 Enums are now used to handle constants (the backported packaged enum34 is installed in older Python version).

There is one more change under the hood. PyVISA 1.6 can discover and use other backends to talk to devices (See here). This feature is allowing us to prototype some new packages about which I am going to blog next week.

All these things are only possible as we have dropped some backwards compatibility requirements. In particular, we have removed the legacy package, the string manipulation functions and all the singletons. Most programs will run without major changes but in any case, all API modifications are documented here to help with the transition.

All this would not have been possible without the support of a great community that has been helping with the development and testing different development versions. But we really need your help before uploading this to PyPI as an stable release. PyVISA is all about interacting with your operating system (finding and locating the C library) and you instruments. With the variety of platforms around, it is very difficult to test. We are asking all users to install PyVISA from the github repository and test it on your programs. You can install PyVISA or upgrade to the development version using pip:
 

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

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/
Share