Mariano Draghi (cHagHi): George R.R. Martin y el poder

Ruling is hard. This was maybe my answer to Tolkien, whom, as much as I admire him, I do quibble with. Lord of the Rings had a very medieval philosophy: that if the king was a good man, the land would prosper. We look at real history and it’s not that simple. Tolkien can say that Aragorn became king and reigned for a hundred years, and he was wise and good. But Tolkien doesn’t ask the question: What was Aragorn’s tax policy? Did he maintain a standing army? What did he do in times of flood and famine? And what about all these orcs? By the end of the war, Sauron is gone but all of the orcs aren’t gone – they’re in the mountains. Did Aragorn pursue a policy of systematic genocide and kill them? Even the little baby orcs, in their little orc cradles?

George R.R. Martin, hablando sobre Tolkien, el poder y la responsabilidad de gobernar.

Fuente: George R.R. Martin: The Rolling Stone Interview (ojo, la entrevista en sí contiene algunos spoilers de la saga A Song of Ice and Fire y la serie de HBO Game of Thrones basada en ella).

La traducción de la cita sería más o menos así: “Gobernar es difícil. Esta [la forma en que los personajes de A Song Of Ice and Fire ejercen el poder] fue tal vez mi respuesta a Tolkien, con quien tengo mis objeciones, a pesar de lo mucho que lo admiro. El Señor de los Anillos tenía una filosofía muy medieval: si el rey era un buen hombre, la tierra prosperaría. Pero si miramos la historia real resulta que no es tan simple. Tolkien puede decir que Aragorn fue coronado y reinó por cien años, y que fue sabio y bueno. Pero Tolkien nunca formula la pregunta: ¿Cuál fue la política de impuestos de Aragorn? ¿Mantuvo un ejército permanente? ¿Cuáles fueron sus medidas en tiempos de inundaciones y hambruna? ¿Y qué pasó con los orcos? Al terminar la guerra, Sauron ya no está, pero los orcos sí — están en las montañas. ¿Acaso Aragorn siguió una política de genocidio sistemático y los mató? ¿Incluso a los bebitos orco, en sus cunitas para orcos?

Roberto Alsina: Mi análisis pascual.

No­ta de Cla­rín de ho­y, Do­min­go de Pas­cua­s:

"La ma­yo­ría de la gen­te cree que la re­li­gión es po­si­ti­va pa­ra la so­cie­da­d"

Es, ob­via­men­te, una en­cues­ta. Y es un ex­ce­len­te ejem­plo de apli­ca­ción de una de las téc­ni­cas que des­cri­bí en mi post "Có­mo men­tir con es­ta­dís­ti­ca­s!" Es­pe­cí­fi­ca­men­te, es una apli­ca­ción de "A­gru­par Re­sul­ta­do­s".

El ti­tu­lar de Cla­rín es por­que "pa­ra el 59% de los en­tre­vis­ta­dos la re­li­gión es po­si­ti­va, mien­tras que el 22% la con­si­de­ra ne­ga­ti­va y el 14% es­ti­ma que no jue­ga nin­gún pa­pe­l." ­Fí­jen­se que pa­ra em­pe­zar ahí fal­ta una op­ció­n, por­que la su­ma da 59 + 22 + 14 = 95%!

Re­par­ta­mos ese 5% en­tre las otras op­cio­nes, y en rea­li­dad los por­cen­ta­jes son 62%, 23% y 15% (re­don­dean­do­). En­ton­ce­s, sí, la ma­yo­ría de la gen­te cree que la re­li­gión es po­si­ti­va pa­ra la so­cie­da­d.

¿Pe­ro qué es más no­ti­cia? ¿Que el 62% de la gen­te cree que la re­li­gión es po­si­ti­va pa­ra ­la so­cie­da­d, o que el 38% de la gen­te cree que no lo es?

En mi hu­mil­de opi­nió­n... lo se­gun­do. Si apli­ca­mos un po­co más de men­ti­ra es­ta­dís­ti­ca, po­drían ha­ber ti­tu­la­do­ "­Cer­ca de la mi­tad de la gen­te no cree que la re­li­gión sea po­si­ti­va pa­ra la so­cie­da­d".

ESO es­ti­ma­do Cla­rí­n, es un ti­tu­lar que pro­vo­ca hi­ts. Y es igual de cier­to que el tu­yo.

Marcos Dione: detailed-osm-mapnik-redering-times

In the last post I concluded that I will reimport Europe's data before applying a new version of my design. This would also mean that I will have to render everything from time to time. How much does this take? Let's answer that question.

Remember first that I didn't quite import all of Europe, just a rectangle with North UK, Portugal, Malta and Istambul as limits, so I'll just render that part. Then comes the question of how deep do it. OSM's wiki has some information about tile usage that shows that only up to zoom level (ZL) 11 all the tiles were viewed at least once, and that after ZL 15 the percentage drops below 10. I strike my balance at 14, where there's a one in three chance of the tile being seen. Then I render specific regions down to ZL 18, mostly my current immediate area of influence and places I will visit.

So with the same bbox as the import step, I fired the rendering process and left the machine mostly by itself. I say mostly because at the end, it's my main machine, and I kept using it for hacking, mail, browsing, chat, etc, but nothing very CPU, RAM or disk intensive. I modified generate_tiles.py so it measures the time spent on each tile and logged that into a file. Then I run another small python script on it to get the minimum, average, maximum and total times, how many tiles were rendered and the space they take[1]. Here's a table and graph that resumes it all:

The scale for all the lines is logarithmic, so all those linear progressions there are actually exponential. You can also see the cut at zoom level 14, and that I ended rendering more or less as many tiles from ZLs 15 to 18 as for ZLs 9 to 13.

The first thing to notice is that the average curve is similar, but considerably lower, to the one I had in my minimal benchmark. Most important, and something I didn't think then, is the total time columns. I have 4 of them: 'total' is the total CPU time in seconds, then I have one for the same time in hours and and another in days. As I actually have 4 CPUs and I run generate_tiles.py on all of them, I have an extra column that show an approximative wall clock time. At the bottom row you can see totals for the times, tile count and space used.

Talking about space, There's another constraint there. See, I have a 64GiB Nokia N9, which is one of, if not the, intended purposes for this map. Those 64GiB must be shared mostly with music, so I don't get bored while driving (specially in the endemic traffic jams in this region). This means that having up to ZL 14 in my phone is unfeasible, but ZL 11 seems more reasonable. This means that I will also have to make sure I have what I consider important info at least at that ZL, so it also impacts the map design.

So, 12.6 days and 84GiB later, I have my map. Cutting down ZLs 12 to 14 should save me some 8 days of rendering, most probably 7. I could also try some of the rendering optimizations I have found so far (in no particular order):

https://github.com/mapnik/mapnik/wiki/OptimizeRenderingWithPostGIS

https://github.com/mapnik/mapnik/wiki/Postgis-async

http://mike.teczno.com/notes/mapnik.html

http://blog.cartodb.com/post/20163722809/speeding-up-tiles-rendering

I was also thinking on doing depth first rendering, so requests done for ZL N can be used to render ZL N+1 (or maybe the other way around). This seems like a non obvious path, so I will probably check if I have lots of time, which I currently don't.


[1] Actually, the space used is calculated by du -sm *, so it's in MiB.


openstreetmap gis

Gonzalo Martinez: Aprendiendo Erlang parte 6 Modulos II

Una última función agregada al modulo, usando ambas funciones anteriores

greet_and_add_two(X) ->
    hello(),
    add(X,2).

No olvides agregar greet_and_add_two/1 a la lista de funciones exportadas. En las llamadas a hello/0 y add/2 no necesitas escribir el nombre del modulo delante de ellos por que son declaradas en el módulo mismo.

Si hubieras querido ser capaz de llamar a io:format/1 en la misma manera que add/2 o cualquier otra función definida en el módulo, deberías agregar el siguiente atributo de modulo al comienzo del archivo -import(io, [format/1]). Entonces podrías llamar a format('Hola Mundo!~n'). directamente. De manera más general puede seguir esta receta.

-import(Module, [Funcion1/Aridad, ..., FuncionN/Aridad]).

Importar una función no es más que un atajo para los programadores cuando escriben su código. Los programadores Erlang a menudo desalientan el uso del atributo -import ya que algunas personas encuentran que reduce la legibilidad del código. En el caso de io:format/2 la función io_lib:format/2 también existe. En caso de que se use una de estas el programador tendría que ir al comienzo del archivo para saber de cual de las dos se trata. Consecuentemente, dejar el nombre de módulo es considerada una buena práctica. Usualmente, las únicas funciones que verás importadas vienen del módulo de listas: estas funciones son usadas con mucha frecuencia  que las otros módulos.

Tu módulo useless debería ahora verse algo así

-module(useless).
-export([add/2, hello/0, greet_and_add_two/1]).

add(A,B) ->
    A + B.

%%
%%
hello() ->
    io:format("Hola mundo!~n").

greet_and_add_two(X) ->
    hello(),
    add(X,2).

Hemos terminado con el módulo 'useless'. Puedes guardar el archivo bajo el nombre userless.erl . El nombres del archivo deberá el nombre del módulo como fue definido en el atributo -module, seguido de '.erl' que es el tipo de extensión standard para Erlang.

Anteriormente vimos como compilar el módulo y finalmente intentar todas sus funciones, veremos como definir y usar macros. Las macros de Erlang son realmente similares a las declaraciones '#define' de C, principalmente usado para definir funciones cortas y constantes. Ellas son expresiones simples representadas por texto que será reemplazado antes de que el código sea compilado por la VM. Tales macros son útiles principalmente para evitar valores mágicos flotando alrededor de tus módulos. Una macro es definida como un atribudo módulo de la forma -define(MACRO, some_value).  y es usada como ?MACRO dentro de cualquier función definida en el módulo. Una 'función' macro debería escribirse como -define(sub(X,Y), X-Y). y usada como ?sub(23,47) luego reemplazado por 23-47 por el compilador. Algunas personas usarán macros más complejas, pero la sintaxis básica se mantiene igual.

Compilando el código

El código Erlang es compilado a bytecode para ser usado por la máquina virtual. Puedes llamar al compilador desde distintos lugares $ erlc flags file.erl en la linea de comandos, compile:file(FileName) en la shell o en un módulo c() en la shell, etc.

Es tiempo de compilar nuestro módulo useless. Abrir la Shell de Erlang y escribir lo siguiente.

1> cd("/path/to/where/you/saved/the-module").
"Path name to the directory you are in"
ok

De manera predeterminada, la shell solo busca archivos en el mismo directorio que esté fue lanzado y en la libreria estandar: cd/1 es una función definida exclusivamente para la Shell de Erlang, diciendole que cambie el directorio uno nuevo por lo que es menos molesto navegar por nuestros archivos. Los usuarios de Windows deberían recordar de usar la barra invertida. Cuando esto se realice haz lo siguiente.

2> c(useless).
{ok, useless}

Si obtienes otro mensaje, asegurate que el nombre del archivo es correcto, que estás en el directorio correcto, y que no tienes errores en tu módulo. Una vez que compiles el código exitosamente, te darás cuenta que un archivo useless.beam fue agregado en el mismo directorio que tu useless.erl. Este es el módulo compilado. Probemos nuestras funciones.

3> useless:add(7,2).
9
4> useless:hello().
Hello, World!
ok
5> useless:greet_and_add_two(-3).
Hello, World!
-1
6> useless:not_a_real_function().
** exception error: undefined function useless:not_a_real_function/0

Las funciones funcionando como esperamos add/2 agrega números, hello/0 muestra por pantalla "Hello World!", y greet_and_add_two/1 hace ambas cosas. Por supuesto, te preguntarás por que hello/0 retorna el atomo ok luego del texto saliente. Esto es por que las funciones Erlang y expresiones deben siempre returnar algo, incluso si ellas no son necesarias en otros lenguajes. Así como, io:format/1 retorna 'ok' para denotar una condición normal, la ausencia de errores.

La expresión 6 muestra un error siendo lanzado por que una función no existe. Si te olvidás de expotar una función, este es el tipo de mensaje de error que obtendrás cuando lo ejecutes.

Hay un montón de banderas de compilación existentes para tenes más control sobre como es compilado el módulo.  Puedes obtener una lista de todos ellos en la documentación de Erlang [0] . Los más comunes son.

-debug_info
Las herramientas de Erlang como debuggers, cobertura de código, y herramientas de analisis estático se usan para la información de depuración de un módulo con el fin de realizar su trabajo.

-{outdir, Dir}
Por default, el compilador de Erlang creará los archivos 'beam' en el directorio actual. Este te permitirá elegir donde poner el archivo compilado.

-export_all
Ignorará el atributo -export del módulo y en su lugar exportará todas las funciones definidas. Este es principalmente útil cuando estás probando o desarrollando código nuevo, pero no debería ser usado en producción.

-{d, Macro} or {d,Macro,Value}
Define una macro a ser usada en el módulo, donde Macro es un atomo. Este es usado más frecuentemente cuando se trata de pruebas unitarias, lo que garantiza que un módulo solo tendrá sus funciones de prueba creadas y exportadas cuando se quieren explicitamente. Por default, Value es 'true' si esta no es definida en el tercer lugar de la tupla.

Para compilar nuestro módulo useless con algunas banderas, deberíamos hacer lo siguiente:

7> compile:file(useless, [debug_info, export_all]).
{ok, useless}
8> c(useless, [debug_info, export_all]).
{ok, useless}

Puedes tambien ser astuto y definir opciones del compilador dentro de un módulo con un atributo de módulo:

-compile([debug_info, export_all]).

Entonces solo compilará y obtendrás los mismos resultados que si pasaras las banderas manualmente. Ahora estamos listos para escribir funciones, compilarlas, y ejecutarlas. Es el momento de ver hasta donde podemos llevarlo.

Tarde y de a poco sigo traduciendo, como salga, pero aprendiendo algo cada día. [1]
[0] http://erlang.org/doc/man/compile.html
[1] http://learnyousomeerlang.com/modules

Marcelo Fernández: FLISOL 2014 en Luján

El grupo de usuarios de Software Libre de la Universidad de Luján –UNLUX- invita a toda la comunidad a participar de la edición 2014 del FLISOL – Festival Latinoamericano de Instalación de Software Libre en la ciudad de Luján, a llevarse a cabo el día sábado 26 de abril, en concordancia con numerosas ciudades de Argentina y el continente. Las actividades se desarrollaran en la Sede Central de la Universidad Nacional de Luján (UNLu) a partir de las 13:00 hs.

Al igual que en ediciones anteriores, los integrantes del grupo instalarán Software Libre (GNU/Linux, Firefox, etc.) de forma gratuita y totalmente legal en los equipos informáticos que los asistentes acerquen al encuentro. Durante la ejecución del mismo se ofrecerán charlas informativas y técnicas sobre diferentes aspectos relacionados con el Software Libre.

Los invitamos a participar acercando sus equipos tanto para la instalación de Software Libre, la resolución de problemas sobre instalaciones existentes o simplemente para participar de una jornada distinta para intercambiar experiencias sobre Software Libre o compartir una tarde en un ambiente agradable.

Sobre el FLISOL

FLISOL 2014 en Luján
El Festival Latinoamericano de Instalación de Software Libre es un evento que se viene desarrollando de forma anual desde hace casi una década, donde se promueve el trabajo colaborativo ayudando a personas a conocer el mundo del Software Libre.
Está organizado por varios grupos de usuarios de los países involucrados congregados alrededor de esta iniciativa que reúne participantes de Argentina, Bolivia, Brasil, Chile, Colombia, Cuba, Ecuador, El Salvador, Guatemala, Honduras, México, Nicaragua, Panamá, Paraguay, Perú, Uruguay y Venezuela, entre otros. En Argentina ya está confirmada la realización de FLISOL en distintas ciudades.

El encuentro está dirigido a todas las personas que desean conocer más sobre software libre, instalarlo y usar sus computadoras preservando sus libertades, en condiciones de legalidad y sin estar preocupados por virus y otros problemas comunes del software privativo. Durante la jornada, se realizan instalaciones en forma totalmente gratuita, mientras que en paralelo se ofrecen diversas charlas de divulgación para promover el uso y la filosofía del Software Libre.

Cronograma de Charlas

El cronograma de charlas se está actualizando constantemente. Revisa los sitios flisol.info/FLISOL2014/Argentina/Lujan o www.unlux.com.ar para estar al tanto de las novedades.

Inscripción

Llenando este formulario, nos ayudas a estimar la asistencia de público y preparar mejor los espacios disponibles:
http://eventosimple.net/event/sp/publication/flisol-unlu/register

Sin embargo, la entrada es libre y gratuita, no es necesario registrarse para asistir a las charlas. Si pensás traer un equipo para instalar o configurar, por favor registrate y lee detenidamente las aclaraciones y datos al respecto.

Sobre el UNLUX

El UNLUX es un grupo de usuarios y entusiastas del Software Libre, que existe desde el 2005 y realiza sus actividades en el marco de la Universidad Nacional de Luján. Participa en el FLISOL desde el 2006, instalando y difundiendo diferentes ventajas de usar el Software Libre en el ámbito Educativo, Social, Técnico, Profesional y Personal.

Para conocer las vías de comunicación, podés empezar por www.unlux.com.ar y suscribirte a la lista de correo y el canal IRC.

En agenda

Diego Sarmentero: Testing QPlainTextEdit and QTextEdit scrolling

I was looking for a way to implement smooth scrolling in a QPlainTextEdit component because the per line scrolling looks awful... and i find out that it seems that that kind of scrolling is not supported in QPlainTextEdit, but it's the default kind of scrolling in QTextEdit, which for my surprise wasn't a specialization of QPlainTextEdit.

QPlainTextEdit version code: http://linkode.org/IYhVW93lpgeEahMDknzfe5

QTextEdit version code: http://linkode.org/xSUXB2BtJ2oFRFshlELyJ


And here is a video of how the scrolling differs between each one: