06.16.16

Review Oculus Rift CV1, comparación con DK2

Dos añazos han pasado desde mi ultima entrada en el blog, han pasado en un suspiro, vueltas que da la vida.

Al tema. Esta tarde me han llegado las Rift cuyo preorder hice en el minuto 55, allá por Enero. Santa paciencia. El tochamen que viene a continuación lo escribí rapidamente para unos foros, pero ha quedado tan largo que he pensado que sería una buena forma de resucitar el blog. Ahí va!

Oculus RIft


Bueno, esta tarde me ha llegado el mío. Voy a dar impresiones desde mi punto de vista de usuario de DK2 desde hace casi 2 años.

En general
Primera impresion: El packaging muy cuidado. A mi estas cosas de unboxings y demás me la soplan, pero no he podido evitar fijarme en lo bien que han cuidado todos los detalles, y eso quita el miedo de sentir “pa que hostias me he gastado ese dineral”, al contrario, piensas que lo ha valido. Viene hasta con pegatinas swag para que la gente que las vea en tu portatil sepa que eres alguien que mola y te pidan autógrafos.

A destacar: el sistema elástico para ponerse/quitarse las gafas, muy buena solucion, especialmente comparado con el del DK2 que era un engorro.

Tiene una tela elástica que evita que entre el polvo a la pantalla interior, cosa que era una preocupación con el DK2. Con el CV1 lo puedes dejar tirado en cualquier sitio sin andar preocupándote en qué posicion es mejor dejarlo para que no le entre el polvo luego.

El cable es una bendición: viene un HDMI y un USB3 de la torre, y a los 20cms se juntan en un solo cable, manteniendo el grosor del cable HDMI a solas, flipante. Se puede pisar sin preocupaciones (no recomendado, pero con el DK2 parecia que iban a enroscarse los cables internamente y acabar rompiendo a la larga), es tan flexible como en el DK2, y tiene una longitud que deja claro que Oculus no tiene pensado limitarse a una experiencia sentada.

Tracking: como acabo de decir, el cable tiene una longitud decente. He hecho pruebas en un espacio de 1.5m x 2m, y sin problemas, desde estar de pie hasta estar agachado en todo ese volumen. El unico problema es si te agachas “con la espalda” mirando hacia la esquina opuesta de la cámara: al haber ahora mismo solo una cámara, tapas el headset con tu espalda y pierde tracking. Pero si te agachas “con las rodillas” mantiene el tracking sin problemas. No he notado perdidas de precisión obvias hasta 2.5m de distancia.
Aparte, como el casco tiene menos inercia que en el DK2, puedes hacer movimientos mas bruscos sin que se te bailen las gafas de posición en la cabeza, por tanto aguanta más caña dando sensación de solidez.

Audio

El audio es muy bueno. No soy audiófilo pero tampoco me conformo con unos cascos cualquiera y me tiro horas y horas comparando antes de comprar unos. Los del rift son semiabiertos, no me han defraudado en absoluto, tienen una respuesta en graves bastante más que aceptable, dicen que de calidad son similares a unos cascos bien escogidos del rango de 100 euros (no cascos en los que pagues marca y diseño). Hay que destacar que el HRTF es una maravilla. En más de una ocasión he podido sentir perfectamente si un objeto estaba detras, delante, encima o debajo gracias a ello. Es similar a unos 5.1, pero con la diferencia de que el tema también funciona en vertical 🙂

Mandos
El mando de XBox no consigo que funcione el pincho wireless en windows 7. Por suerte ya tenia otro mando identico pero su cable gigantenorme, asi que ese estoy usando de momento para moverme por la habitación. Si algun dia windows update se digna a funcionar, se bajaran los drivers del wireless y lo usaré.

El otro, el minimando, es util para subir/bajar el volumen sin andar buscando el teclado, tiene incluso indicador de bateria en Oculus Home, y es perfecto para experiencias simples de poca interacción en las que no estes sentado frente al teclado. Otro de los motivos por los que creo que Oculus va a cambiar su postura de “seated experiences only”.

El elefante de la habitacion son los Touch, porque no están. Si los rumores son ciertos los veremos antes de fin de año, y van a caer 100% fijo dadas las buenas reviews que estan saliendo.

Imagen

Calidad visual: lo que todo el mundo se pregunta. El SDE (el espacio negro en pixeles adyacentes) esta practicamente solucionado. Si te pones a buscar lo encontrarás, pero en condiciones reales de uso, no se nota.
Queda por tanto el tema principal, la resolución. Se nota la mejora respecto a DK2, y yo creo que merece la pena el upgrade. Para haceros una idea, si poneis el DK2 con pixels per display pixel a 2x (osea, renderizando a más de 4k), entonces el CV1 se ve en toda la pantalla algo mejor que el DK2 en el centro de sus lentes. Si al CV1 le poneis el p/dp a 2x ya la diferencia es clara.

Si alguno le da al Elite Dangerous, con el CV1 se pueden leer absolutamente todos los textos sin tener que inclinarse para verlos más cercanos.

Las lentes estan bien, tienen mas o menos el doble de área de enfoque que en el DK2. Su forma no-circular ayuda a darte más espacio para no chocar con la nariz (el DK2 acaba tocandome las narices con sus amplias lentes, tanto literal como figurativamente), y el ajuste de IPD es muy comodo de usar, modificable al vuelo en cualquier momento desde el menú de Oculus (por si andas haciendo demos al personal y quieres que lo vean perfecto).
Respecto a lo de que sea lentes fresnel hibrida o no, lo unico en que se nota es en los dichosos rayos de dios (god rays). Por si alguien no los conoce, se rata de unos rayos de luz (muy difuminados, eso sí), que parten desde los pixeles más luminosos hacia el exterior de la lente (de forma radial, desde el centro de la lente, para entendernos). Algunos dicen que solo se nota en escenas de alto contraste. Yo lo noto tambien en situaciones de contraste medio-alto. Por ejemplo, el lado a la sombra de un arbol, contrastando con un cielo azul de fondo. Tal vez me acabe acostumbrando y lo acabe ignorando inconscientemente (seguramente si), pero tras 2 horas de uso son claramente visibles y tocan un poco las pelotas. Pero nada grave, simplemente soy un poco quisquilloso.

La diferencia entre 60Hz con alta persistencia y 75Hz con baja persistencia en el DK2 era apreciable. La diferencia entre los 75Hz del DK2 a los 90Hz del CV1 yo sinceramente no la noto de forma directa. Lo que si que creo es que contribuye a la famosa “presencia”. Con el DK2 he tenido muy muy pocos momentos de presencia (de esto que te da por sacar la mano a intentar coger o mover algo, o a apartarte para esquivar un objeto), pero con el CV1 ya he tenido un par en el día de hoy. La escena del T-rex del dreamdeck ha sido una de ellas. Estoy seguro de que el audio con HRTF tambien ha contribuido a ello.

-fútbol +carreras
Ahora voy con el uso en simracing, que es el mayor uso que le doy. En concreto probado con Assetto Corsa. Si con DK2 cuestra leer el tacómetro y demás (hay que acercar un poco la cabeza para poder leer los numeritos), en el CV1 se leen sin tener que acercarse. Los menues se pueden leer todos sin moverte, los textos mas pequeños no estan tan nitidos, pero son legibles, por poco. Ahora, si habilitas el pixel per display pixel poniendolo a 1.4x, la diferencia es clara. Para mi ese es el punto en el que las CV1 me parece “suficiente” sin lugar a dudas para juegos de coches. SI lo subes a 2.0x la cosa mejora algo más, pero en mi equipo en concreto (gtx970) no consigo renderizar esa resolucion de más de 4k a 90fps, me quedo en entre 60 y 90fps segun el circuito y los coches que haya. El que tenga pepinos de la serie 1000, que lo pongan a 2x y disfruten.
Otra cosa que si que se aprecia claramente aqui son los 90Hz cuando miras por los cristales laterales del coche a velocidad. Se ve pasar el paisaje con mas nitidez que en DK2. Entre la resolucion extra, el SDE arreglado, y los 15Hz extra, es algo que se puede notar.
Mirando hacia adelante esos Hz extra no son apreciables conscientemente, pero inconscientemente ayuda a asentar el mundo virtual y que parezca todo más realista, más “estoy ahí metido de verdad” de presencia esporádica, comparado con el DK2. Yo al menos lo noto bastante.

Deberia escribir un libro. Perdon por el tocho pero seguro que a alguno le ayuda para decidirse 🙂


Hasta ahi llega la review tras 3 horas de uso. Ahora toca plantearse si vendo el DK2 o lo conservo de recuerdo.

07.5.14

Presentación GIT & GIT-SVN

Aprovechando la coyuntura, publico también unas transpas de una charla que dimos hace mil en la oficina, esta vez en spanish. Estaba orientado a novatos totales del git, pero familiarizados con svn:

07.5.14

Grokking Git in 8 slides (for svn users)

Made this at work, it’s how I would have liked to learn Git when I started toying with it some years ago.

Note that not a single Git command is explained. Instead, a series of images show how Git works, and what’s possible to do with it.

Looking up the actual (and unintuitive) commands and flags is left as an exercise to the reader 🙂

 

IMPORTANT: the presentation notes are only visible in the original Grokking Git presentation (bottom panel, right below each slide), but here’s an embedded version anyway, for those too lazy to click the link:

02.1.14

Hacking the LGA 775 socket

 

Hello, and welcome to CPU Dealers!

In todays episode we’re going to learn how to fit an LGA771 CPU into an LGA775 motherboard with no brute force!

 

Motivation

So why on earth would anyone decide to put an LGA771 Xeon server cpu into a domestic LGA775 motherboard, you may ask?

Welp, because it’s fun and you get to learn stuff, thats why!

Traditional motivation: Money

However, the usual argument is that, if you are planning a modest upgrade for your shitty old LGA775 system, not needing the latest and greatest, you can save some money this way. See, there’s lots of Xeon processors in the market right now, and they are all dirt cheap. The interesting thing is that most LGA775 CPUs have Xeons equivalents:

Xeon E5440: 30€ vs Core2Quad Q9550: 100€

The Xeon I chose, an E5440 SLBBJ. Same speed as a Q9550, but requires less juice, so has a lower TDP. Source: here and there.

Some people argue that Intel simply bins Xeons better than the consumer counterparts, so while being essentially the same CPU, the Xeons are more reliable, run colder, and are harder, better, faster, stronger.

The LGA775 market, on the other hand, is filled with pretty expensive CPUs. They’re all usually priced 30€ to 150€ higher than the server versions: Xeons are definitely the best bang for the buck. So the plan usually is:

  1. Upgrade your system to a Xeon instead of a domestic CPU.
  2. Fun and profit!

Side motivation: Overclocking

Some people take advantage of the lower voltages required by Xeons, and choose them not only because they’re cheaper, but because it’s in theory easier to squeeze a bit more speed out of them.

Keeping that in mind, I chose an E0 stepping (later revisions usually lower power requirements of the CPU). Unfortunately, my SLBBJ unit was already running pretty hot at stock voltages and clocks, so I’m leaving it alone for the time being.

Background

LGA775 (codenamed Socket T) was introduced by Intel around mid-2004, and used in domestic motherboards. The most popular CPUs running those LGAs are now Core2Duos and Core2Quads.

A year and a half later, in 2006, Intel introduced LGA771, a very similar LGA intended for use in multiprocessor server motherboards, and which can host Intel Xeon processors.

Looking at the official datasheets released by Intel (page 41 here and page 52 here) , we can check the pinouts of both LGAs, and spot their differences:

775 pinout 771 pinout

If we checked the socket pin assignment one by one, we could see that there’s 76 different pins in total. But most of them are irrelevant (reserved for future uses, etc), they pose no problem for our conversion mod, so we’re left wondering about the colored pins:

  • Red: 8 pins only used in LGA775.
  • Green: 4 pins only used in LGA771.

The red and green pins are all power pins (VCC, VSS at the top, and VTT at the bottom). There’s hundreds more of them in the LGA, so I’m sure our new CPU won’t mind if we remove just these few.

  • Blue: 2 pins that have different purposes in each LGA.

These pins (L5 and M5) serve different purposes in LGA775 than in LGA771. And this time they are important pins (one of them is the Execute BIST pin, Built-In Selft Test, needed to boot). Fortunately, Intel had simply swapped their places in the newer 771 LGA! So it should be relatively easy to re-wire them.

  • Yellow: not a pin, just highlighting the different shapes 🙂

These differing yellow shapes can be a problem, since the CPUs from one LGA will not physically fit in the other LGA without some hardware modifications. We’ll get to this later on.

 

Uh, in case you’re wondering, I did not personally go over all the pin specifications one by one. But this guy did.

Motherboard support

In most cases, the CPU will run as-is. This was the case of my 965P-DS3 motherboard.

Sometimes, you may need to manually patch your BIOS, adding the microcode of your specific Xeon model to the internal “whitelist” (so to speak). Additionally, this usually forces your mobo to acknowledge that your Xeon CPU implements the SSE4 instruction set (which can give an extra speed boost in some applications).

Opening an hex editor automatically grants you 15 Hacker Points.

I didn’t patch my BIOS just yet… so instead, I decided to steal this screenshot from Google Images. Sue me.

And in a few rare cases, your motherboard will directly refuse to boot the new CPU, regardless of any BIOS patching you may attempt. In that case, you’re out of luck.

Before attempting to transform your LGA775, search the web and check if your chipset will be happy with a Xeon CPU.

In any case, bear in mind that your mobo needs to support the speeds that your specific Xeon choice requires: voltage, FSB speeds, etc. Otherwise you’ll have to resort to underclocking the CPU (sad), or to overclocking your motherboard/ram (yay! but not recommended).

Procedure

First, open your tower, remove the heatsink, then the CPU:

Speaking of heavily overclocked CPUs, anyone wants to buy this E4300 in perfectly good shape? Never overclocked, almost new, I swear.

There lies my old Core2Duo E4300, overclocked to hell, ready for retirement.

Now we do what the title says: we hack the LGA775 socket. Literally.

Yes, take a sharp knife or a cutter, and prepare to slash some plastic. The exact bits you have to cut off are the ones colored yellow in the LGA775 pinout diagram (scroll back to the beginning of this post). It should end up looking something like this:

Don't mind the bent pins on the middle bottom. This is embarrasing...

Actually, please try to aim for cleaner cuts than the mess you see in this photo.

The motherboard is ready!

Now we need to hack the Xeon CPU itself. Remember the blue pins that had switched places in LGA771? It’s time to revert what Intel did, and get a 775-compatible pinout layout.

If you’re good enough you could try to swap them yourself, using whatever technique you come up with. But the rest of us mortals will resort to buying a ready to use swapper sticker. Search for “775 771 mod” in ebay, play safe and buy several of them, just in case you break one in the process:

Wow. Such pins. Many carefuls. Much Intel. It Xeons!

Be very careful with the sticker, it’s very easy to break its internal wiring.

So there’s that. Now we simply have to put the Xeon in the LGA, add thermal paste, heatsink, etc:

This photo adds absolutely no value to the article. It was lying in my phone, all alone. So I decided to upload it, with the rest of photos.

Yay, we’re done!

Finally, plug the PSU, pray to Flying Spaghetti Monster, and boot the system!

 

Results

Here’s a nice comparison graph of the results. The contenders are:

  • A Core2Duo E4300 (LGA775), at speeds ranging from 1.8GHz (stock) up to 3.01GHz (overclocked).
  • A Xeon E5440 (LGA771), at stock speed (2.83GHz).

The benchmarks are:

  • Assetto Corsa, a multithreaded racing simulator (M30 Gr.A Special Event), FPS measured with my own plugin FramerateWatcher.
  • PI calculator SuperPI, 2M variant, running in a single thread.
  • Average maximum temperature reached by all cores, over a period of 15 minutes running In-place large FFTs torture test in Prime95.

 

...drum roll...

And the winner is…

The winner is the Xeon, as it should: specially in multithreaded programs, the Xeon obliterates the Core2Duo.

But it’s interesting to note that, even running at the same clock speed of around 2.8GHz, the Xeon outperforms the Core2Duo by more than 20% in single threaded applications.
I checked the FSB and RAM multipliers in both cases, just in case the Xeon had an advantage on that front, but it was actually the E4300 which had higher FSB and RAM clocks!

Goes to show how clock isn’t everything when it comes to performance, and obviously better CPU technology consists of more than higher clock freq and greater number of cores.

The end

So that’s it, that’s the story of how I more than doubled the framerates in games and halved compilation times for the cost of 4 movie tickets.

Hope you enjoyed reading this article as much as I definitely did not enjoy proof-reading it! 😉

08.7.13

In defense of unformatted source code – breakindent for vim

Everyone knows that Opera is better than Firefox,  Vim+Bash is better than any IDE, and 4-space indenting is better than tabulators. Having established those undisputed facts of life, let’s revisit some common fuel for flame wars: the mighty 80 character line limit.

 

80x10 "IBM Card" from 1928

Fortran code punched into a 80 x 10 IBM Card from 1928

 

Some people propose 80 chars, others 79, 100, 120, 132 , and many values in between.

Some people propose it should be a soft limit (meaning you can freely ignore in rare cases), while others set pre-commit hooks to stop any infringing line from reaching repositories.

None of this really matters.

The 80 character line limit, originated by hardware limits back when computer terminals were only 80 chars wide, or even further back in time, is said to provide many advantages. To name a few:

  • Better readability when opening two files side by side (for example, a diff)
  • Quicker to read (same reason why newspapers use many columns of text, instead of page-wide paragraphs: human brain scans text faster that way).
  • It forces you to extract code into separate functions, in order to avoid too many nesting levels.
  • It prevents you from choosing overly long symbol names, which hurt readability.
  • Etc.

I propose that those advantages are real and desirable, but should not be achieved through arbitrary line length limits. On the contrary, I propose that coders should not waste time formatting their source code: their tools should do it when possible. After all, we use text editors, not word processors! The problem is that, unfortunately, most text editors are too dumb.

Fix the editors, and you fix the need for line length limits.

 

If you edit your code in vim, you’re in luck, thanks to the Breakindent functionality. Here’s some side-by-side comparisons of 80-char line limit vs. unformatted text with BreakIndent enabled:

80x35

(left: 80-char                  right: breakindent)

Traditional terminal size:

Resizing your terminal to exactly 80 chars wide, both cases look pretty similar. Nothing to see here, move along.

 

 

208x16-26

(top: 80-char                     bottom: breakindent)

Wide terminal:

If you want to edit just one file, an 80-char limit will waste the rightmost half of your screen (or more).

 

 

 

40x50

(left: 80-char                   right: breakindent)

Narrow terminal:

If you’re three-way merging (or need to keep code aside for a moment, etc) those 80 chars will either wrap around or disappear from view, making the code harder to read.

 

 

All in all: when compared to an editor featuring smart indenting, the 80-char lines artificially limit how you can resize your own windows, with no appreciable gain, and in most cases forcing you to waste many pixels of your carefully chosen 27″ dual-screen coding setup.

05.17.13

Trick of the day: rendering graphics in your terminal

“Those who cannot remember the past are condemned to repeat it”

— Jorge Agustín Nicolás Ruiz de Santayana y Borrás

limecat

Over the past few years, a number of “graphic terminal” emulator software have emerged. Some examples:

This is nothing new, in fact it was possible back in the 70’s, and you can try it using XTerm, the default terminal emulator bundled with X installations since forever!

The process is very simple, you simply have to run:

$ xterm -t -tn tek4014

Which will start an xterm emulating a TEK4014 terminal (instead of the default VTxxx plain-text terminal).

Tektronix_4014

TEK4010 terminal

Now we’ll download some images we want to display. These 40 year old terminals don’t support JPEG though (it didn’t exist back then), nor any popular modern image format, so we’ll have to provide images in a format they understand. Plotutils includes a couple of these vectorial images, so we will run:

# apt-get install plotutils

And finally it’s simply a matter of feeding the Tek4014 terminal with an image, for example:

$ zcat /usr/share/doc/plotutils/tek2plot/dmerc.tek.gz

The terminal will  be fed with an appropriate escape character sequence, along with the actual image contents, it’ll interpret it as an image (just like other escape sequences are interpreted as colored or underlined text), and the awesome result will be this:

 

xterm

How cool is that? 🙂

 

You can even resize the terminal window, and the graphics will be re-rendered with the correct size (remember it’s a vectorial image, so wen can zoom in indefinitely).

 

01.31.13

Helpful VIM highlighting

Here’s a quick snippet that you can add to your .vimrc in order to get:

  • MS Visual Studio-like ‘current word‘ highlighting.
  • Trailing space highlighting.

The result looks like this:

vim_hl

And the code is:

1
2
3
4
5
6
7
8
9
10
11
12
function Matches()
    highlight curword ctermbg=white ctermfg=black cterm=bold gui=bold guibg=darkgrey
    try
        call matchdelete(w:lastmatch)
        unlet w:lastmatch
    catch
    endtry
    silent! let w:lastmatch=matchadd ('curword', printf('\V\<%s\>', escape(expand(''), '/\')), -1)
    highlight eolspace ctermbg=red guibg=red
    2match eolspace /\s\+$/
endfunction
au CursorMoved * exe 'call Matches()'

Yes, one day I might convert it to a vim plugin, meanwhile just copy-paste to your .vimrc.

Enjoy!

12.3.12

HTML5 + Box2D = Quick’N’Dirty Dakar Rally Sim

I very rarely mess with web development these days, but the power of current JavaScript engines and latest HTML5 features were just too juicy to pass on.

So sometime around early 2011, I took two afternoons and played with these technologies. Just now I remembered the project I had in hands, and decided I could give it a name and publish it on the net for your personal amusement.

Consider it pre-alpha, and expect bugs! 🙂

qnd_dakar_rally_sim

Features:

  • Infinite landscape, using procedural generation (how else could I squeeze infinity into a few KBs?), and adaptive terrain features based on play style (namely, how fast you like to drive).
  • Somewhat realistic physics (based on Box2dJS library).
  • Incredibly detailed graphics engine based on WebGL. Nah just kidding, it’s the default HTML5 canvas-based rendering provided by Box2D itself…
  • Physically-modelled rolling stones on the driving surface. Framerate suffers too much so they’re disabled by default. To re-enable, dive in the source code and hack away.
  • Tested on major PC browsers, and on Dolphin Browser Mini on Android.

Controls:

  • right-arrow -> gas
  • left-arrow <- brake

Right now I’m in the middle of a physical home migration so the code is not githubbed yet, but you can access it by clicking the following link:

Quick’N’Dirty Darkar Rally Sim 2011

There’s no purpose as of yet, but you can try to race against the terrain and see how far you last before ending up on your roof or suffering a physics explosion.

License is GPLv3.

11.27.12

Tramitar baja de ADSL YaCom

Interrumpimos temporalmente la emisión de posts en este blog para meter un offtopicazo, porque no me cuesta nada, y si con esto consigo ayudar a algún alma perdida de dios que quiera dar de baja su linea ADSL de yacom (ahora orange), pues algo bueno habré aportado…

 

Procedimiento a seguir (comprobado el día 27-11-2012):

  1. Obtener el número de referencia de la baja:
    1. Usar el teléfono 900 900 282 (número  gratuito, aunque no aparezca a día de hoy en nomasnumeros900). Insistir varias veces si nadie coge, a la tercera va la vencida.
    2. Tras una breve charla (de verdad, es breve) sobre el motivo de la baja, se te facilitarán unas instrucciones (que proveo a continuación), así como un número de baja (de 9 cifras en mi caso concreto).
    3. Dar las gracias si la persona que te ha atendido ha hecho un buen trabajo y si te apetece (porque ir de pitufo gruñón por la vida no lleva a nada).
  2. Enviar la carta:
    • Remitente: tú mismo…
    • Destinatario: YACOM – Apartado de Correos 35809 – CP 28080 – Madrid
    • Contenido:
      • Carta escrita con:
        • Nombre y apellidos del titular de la cuenta.
        • Tu número de teléfono fijo contratado con YACOM.
        • El número de contrato
        • El motivo de la baja, por ejemplo “Cambio de domicilio”, “Defunción por suicidio tras intentar dar de baja la línea durante varios días”, o cualquier otro motivo igualmente creíble.
        • El número de baja que te han facilitado antes por teléfono.
        • Firma del titular de la cuenta.
      • Fotocopia del DNI por ambas caras.
    • Las gentes de internet recomiendan no enviar una carta tradicional, sino un burofax, aunque vale con una carta certificada. El tema es que no pongan excusas tontas para seguir cobrándote durante meses.
  3. La baja se comenzará a tramitar al de 7-10 días de recibir la carta/burofax (aunque legalmente disponen de hasta 15 días, no solamente 7 ó 10). En ese momento dejarán de facturar.
  4. Después, esperar a que cobren la última factura. Desde su adquisición por parte de Orange, los cobros de YACOM se realizan después (y no antes) de cada período de facturación (que es del día 16 del mes anterior, al 15 del actual), por lo que tras recibirse la carta/burofax, quedará por llegar la última factura. Ésta debería estar prorrateada para reflejar los días reales que se ha utilizado la línea, y no necesariamente el período completo de facturación. La factura llegara a finales de mes.).
  5. Por su seguridad, y con el justificante de envío de la carta/burofax en mano, mandar orden al banco de rechazar recibos de YACOM.
  6. Alea jacta est!

 

Por último, no hace falta que leais este párrafo a partir de este punto, porque esgrimiendo mis increíbles habilidades de ese-e-o, escribiré algunas palabras clave para que la gente que quiera dar de baja, cancelar, eliminar o dejar de pagar su línea de conexión de acceso a Internet de banda ancha de ADSL con teléfono fijo del proveedor de Internet y telefonía fija YACOM, a veces también llamado ya.com, y comprado recientemente por Orange, pueda encontrar este post mediante busquedas tan típicas como “Quiero dar de baja mi linea de YACOM”, o “Cómo cancelo mi conexión de internet con ya.com 10 megas”, o tal vez “Hoygan no consigo dar de baja mi adsl de yacom, ¿cómo hago?”, o incluso “Me gusta el olor a ISP quemado por la mañana”, en su buscador preferido.

 

Muchas gracias por su atención, y tengan un buen día.

 

10.24.12

Liberación de recursos en python

Pongámonos en contexto: estamos usando Python, un lenguaje no mucho más viejo que Java, y donde una de las primeras lecciones que se aprenden es que la memoria es gestionada automáticamente.

Hurrah! Ya no hay que hacer mallocs, ni deletes, ni tener destructores, ni hostias en vinagre,  porque python lo hace todo!

 

¿Entonces, por qué nos topamos a menudo con código como éste?:
f = open("foo.txt", "r")
text = f.readlines()
f.close()        # WAT.
O bien esto?:
with open("foo.txt", "r") as f: # WAT.
    text = f.readlines()

Y no hablo solo de ficheros, sino cualquier tipo de recurso: conexiones de red, puertos hardware, primitivas de sincronización, memoría RAM, etc.

(nota: el texto a continuación es básicamente un copiapega de un mail  enviado a una lista de correo privada. lo digo por si algo no encajara…)

Vamos a meternos en detalles (al menos hasta donde yo conozco; y no dudeis en corregirme si veis algún fallo, así aprendemos todos):

No es necesario hacer un close:

Es cierto, no es estrictamente necesario hacer un close, porque por defecto el lenguaje python se encarga de esas tareas mundanas por nosotros. El problema es que lo hace automáticamente, y a su manera, y puede que no sea la que nos interese.

De ahí que se suela hacer un close() explícito (ya sea con una llamada directa, o mediante el “with” que he comentado antes).

¿Por qué podría no interesarnos lo que hace python por defecto?
Puede ser por muchos motivos:

La vida de las variables en python es un detalle de implementación:

Por ejemplo, el intérprete que solemos usar (CPython) mantiene los objetos en memoria como mínimo hasta que salen de ámbito, y como máximo hasta cuando el GC de CPython lo determina en alguna de sus pasadas (cuando existen ciclos de referencias, y según el perfil de uso de memoria de nuestro programa).

En cristiano: que una variable que se sale de ámbito, podría eliminarse al momento, o podría tardar media hora en ser eliminada por el GC. Imaginad que las conexiones a una misma cámara IP solo se cierran cada diez minutos (porque hemos delegado todo al GC), y que esa cámara acepta como máximo 4 conexiones simultáneas…

(otras implementaciones como PyPy, Jython, IronPython, etc. pueden comportarse distinto)

En .NET ocurre lo mismo, como bien dice David (de ahí viene el jaleo de usar iDisposables incluso para recursos managed…), y en Java más de lo mismo.

Bugs de terceras partes:

Alguna vez hemos sufrido bugs de conteo de referencias, por alguna librería de python escrita en C que no actualizaba correctamente los conteos y provocaba leaks de nuestros propios objetos.

Si esos objetos tenian recursos abiertos, hay que cerrarlos a mano, o sino seguirán abiertos hasta que muera nuestro proceso de python.

Bugs propios:

Incluso asumiendo una gestión de memoria perfecta e instantánea por parte de CPython (que no es el caso necesariamente, como he explicado), existen casos en que nuestro código puede estar manteniendo variables en memoria (y con recursos abiertos) sin que nos demos cuenta.

Algunos casos típicos:

Variables de instancia:

def __init__(self):
    self.my_file = open(...)
    print self.my_file.readline()
    # el recurso permanecerá abierto al menos
    # hasta que el objeto self sea eliminado

Variables dentro de una función de larga duración:

my_file = open(...);
print my_file.readline()
while True:
    # bucle principal del programa
    # my_file sigue con el recurso abierto al
    # menos hasta el fin de la función

Variables que por su naturaleza son compartidas:

El ejemplo más claro, un mutex. También semáforos, bufferes de memoria compartidos por varios hilos, etc.

Variables referenciadas por closures:

Aunque salgamos de una función, los closures alargan la vida de las variables que cogen prestadas de su función padre:
def my_function():
    my_file = open("foobar")
    def internal_function():
        return my_file.readline()
    return internal_function
my_closure = my_function()
# my_file sigue existiendo y con el archivo
# abierto, hasta que se destruya my_closure

Ámbito de función, no de bloque:

Es algo básico de python, pero no está mal repasarlo: en python no vale definir una variable dentro de un bloque (por ej. dentro de un for), porque su ámbito es siempre de función:
for path in ["/a.txt", "b.txt"]:
    my_file = fopen(path...)
    print my_file.readline()
print path    # va a imprimir "b.txt", aunque
              # estemos fuera del bucle.
print my_file # lo mismo pasa con my_file, aunque
              # pueda ser anti-intuitivo
del my_file   # si queremos que se elimine esta
              # referencia a la variable, y el GC
              # pueda hacer su trabajo en algún
              # momento indeterminado
while True:
    #bucle principal de duración infinita
Bueno, creo que así queda una explicación más completa (y espero que también sea técnicamente correcta!) 🙂