My Whole Blog
Total Page：16
File Type：pdf, Size：1020Kb
My Whole Blog Contents Definiendo sintaxis y comportamiento 4 Creando el template 5 A los bifes 7 Los parámetros ................................ 7 Entendiendo los Nodos ............................ 9 Entendienfo figure ............................... 9 Explicando el método run ........................... 10 Explicando el método _render_svg ...................... 11 El método _resolve_render_name ....................... 12 El método _separate_content ......................... 13 Pensando en sphinx 13 Y como se usa todo esto 14 Y funciona? 14 Concept 82 The binding side of things 85 What should a shell scripting language be like? 145 What doesn’t matter? 146 Now, the example 147 Why not use reportlab directly? 285 So, how do you do a report? 286 Trickier: tables 287 Frobniz time measurements 288 How would it work? 288 Missing pieces 289 1 Introduction 369 1. Grok the Disqus API 370 2. Grok the Haloscan comments file 371 3. Create the necessary threads and whatever in Disqus 371 4. Post the comments from Haloscan to Disqus 372 5. Hack the blog so the links to Haloscan now work for Disqus 374 What the Ipad means 384 The User, In Linux 389 The User, in Windows 389 The Developer, in Linux 389 Windows for the developer 391 Problem 1: You need an installer ....................... 391 Problem 2: system libraries don’t exist .................... 393 Creating a plugin 396 Making the Plugin Configurable 397 Making it Work 398 Titanic 417 I’m Mark Shuttleworth! 418 Python vs. Ruby 418 Butter 418 Visa discount! 418 A Stable Deployment Target 478 Deployment Services 478 Monetization Services 478 The Store Itself 478 Intro 491 Chucherías Chinas 491 Cómo Pagar 492 2 El amigo que viene de afuera 492 Accesorios 493 Conclusión 494 Cooking is easy 498 Cooking is fun 500 Cooking is good for you 500 Cooking is cheap 501 Cooking is Applied Nerdiness 501 He’s Ill-Defined 502 The Excluded Middle and Popularity 502 It’s Unethical to Believe in Heaven and Hell 503 Conclusion 503 Proxy Support 524 Persistent Cookies 524 Using Properties and Signals in Object Creation 525 Download Manager 526 Printing 528 Other Tricks 528 Features 634 Bugfixes 635 Filters 636 Bundles 637 Conclusion 637 Hosting 670 Distribution 670 Web Server 670 Mail Server 671 3 Misc 672 Status 673 Docutils System Messages 686 Sorry, spanish only post! Estimado público lector, una cosa muy especial: un post que no escribí yo! Dé- mosle una bienvenida al autor invitado, Juan BC! Una de mis promesas en el año fue terminar uno de los proyectos mas ambi- ciosos que me había propuesto: terminar mi ambientación de rol utilizando el sis- tema matemático que había diseñado junto con un amigo tiempo atras llamado Cros aprovechando la barbaridad de imagenes que tenía guardada de mi tesis de grado. Como no puede ser de otra manera como miembro de Python Argentina utilice el programa utilizado por rst2pdf creado por Roberto Alsina el cual es el dueño de este blog En un punto necesitaba hacer una especie de plantillas de dibujos para repetir el estilo donde hay descripciones de un personaje pero el estilo se mantiene, como por ejemplo las tarjetas de este manual de DC Universe RPG : y me dije a mi mismo ¿Por que demonios no puedo dibujar un svg_ dejar espacios en blancoy luego los lleno dentro del svg? En definitiva, me imaginaba algo así: .. template_svg: path/a/mi/archivo/svg/que/tiene/las/variables/definidas/adentro.svg :nombre_variable_1: valor_de_variable_1 :nombre_variable_2: valor_de_variable_2 ... :nombre_variable_N: valor_de_variable_N Entonces me puse en campaña para poder programar el código python que realiza esa tarea como una extensión de rst2pdf. AVISO!!! este texto lo llevara a usted por cada una de las desiciones dediseño que involucran la creación de mi extensión para rst2pdf Definiendo sintaxis y comportamiento Por empezar aprendí de las limitaciones de la directiva, decidí un nombre para ella y definí cual era el comportamiento que hiba a tener. 4 • Dado que una directiva como template_svg me sonaba a larga decidí que el nombre sería svgt (SVG template). • Las directivas soportan parámetros fijos, no puedo tener un número variable de argumentos para pasarle: nombre_variable_1, nombre_variable_2, variable_N a algo como directiva(**kwargs). Mi solución fue pasarle todo en un json. • Por último definí que svgt generaría un nodo de tipo figure con lo cual mi directiva aceptaría, además de mis parámetros, los argumentos que ya tenía in- corporados en dicha directiva. Esta última decisión me llevó también a contemplar que el archivo svg debería convertirse en un png, y para esto utilizaría la herramienta Inkscape con una llamada al sistema para realizar dicha conversión (la gran ventaja de inkscape es que puede correr totalmente headless con el parámetro -z). En definitiva mi directiva tomaría un nodo asi: .. svgt:: file.svg :vars: { "nombre_variable_1": "valor_de_variable_1", "nombre_variable_2": "valor_de_variable_2", ..., "nombre_variable_N": "valor_de_variable_N"} <figure parameters> Y lo convertería en un nodo así .. figure:: file_con_parametros_resueltos.png <figure parameters> Creando el template Yo uso para crear svg a Inkscape y no pensaba en ningún momento dejar de hacerlo para crear este proyecto. Así que solo era cuestión de abrir el programa y poner en la parte de donde se referencia a una url de una imagen o en un texto algún formato que indique que eso es una variable (recordemos que por dentro el svg no deja de ser texto plano). Para elegir el lenguaje de template decidí utilizar el formato que propone la clase Template que viene en la librería estandar de; la cual dispone que las declaraciones de hacen anteponiendo el símbolo $ al nombre de la variable y pudiendo o no este nombre estar encerrado entre { y }. Por ejemplo en el siguiente imagen se ve como declaro dos variables con Inkscape 5 Por otra parte inkscape desde consola se ejecuta de la siguiente manera para con- vertir un svg a png :: $ inkscape -z file.svg -e file.png -d 300 Donde: • inkscape es el comando para correr inkscape. • -z sirve para deshabilitar el entorno gráfico. • file.svg es el archivo a convertir. • -e file.png indica que se va a exportar el archivo file.svg al for- mato png y se guardara en el archivo file.png. • -d 300 dice que el archivo file.png se creara con 300 dpi de cal- idad. Con esto me genero los siguientes problemas: • ¿Qué sucede si otro me pasa un template y no se cuales son las vari- ablesque tiene adentro? • ¿Y si inkscape no está en el path de ejecución? • ¿Y si no me gustan los 300 dpi de calidad? A este punto usted lector ya se dara cuenta que todo se trata de agregarle mas variables a nuestra sintaxis ya definida: con lo cual todo este cachibache quedaría así: .. svgt:: file.svg :vars: { "nombre_variable_1": "valor_de_variable_1", "nombre_variable_2": "valor_de_variable_2", ..., "nombre_variable_N": "valor_de_variable_N"} :dpi: 72 :inkscape_dir: /usr/bin :list_vars_and_exit: <figure parameters> Siendo: • :dpi: 72 dice que el archivo generado para la figura resultante tendra 72dpi. • :inkscape_dir: /usr/bin indica que el comando inkscape vive dentro de la carpeta /usr/bin • :list_vars_and_exit: establece que svgt solo listara por stdout la lista de variales existente dentro de file.svg y luego el programa terminara (notese que solo tiene motivos de debuging). En código python sólo hay que crear un string con esos huecos y luego llenarlos como en el siguiente ejemplo: 6 \ :kn:‘import‘\ \ :nn:‘os‘\ \ :n:‘cmd‘\ \ :o:‘=‘\ \ :s:‘"{isp} {svg} -z -e {png} -d {dpi}"‘\ \ :k:‘print‘\ \ :n:‘cmd‘\ \ :o:‘.‘\ \ :n:‘format‘\ \ :p:‘(‘\ \ :n:‘isp‘\ \ \ :n:‘svg‘\ \ :o:‘=‘\ \ :s:‘"file.svg"‘\ \ :p:‘,‘\ \ :n:‘png‘\ \ :o:‘=‘\ \ :s:‘"file.png"‘\ \ :p:‘,‘\ \ :n:‘dpi‘\ \ :o:‘=‘\ \ :s:‘"72"‘\ \ :p:‘)‘\ \ :p:‘[‘\ \ :n:‘out‘\ \ :p:‘]‘\ \ :o:‘/‘\ \ :n:‘usr‘\ \ :o:‘/‘\ \ :nb:‘bin‘\ A los bifes Ahora si leyendo el manual de como crear directivas para docutils uno se encuentra que el esqueleto mínimo para crear estos bichos es el siguiente: \ :c:‘# imports necesarios‘\ \ :kn:‘from‘\ \ :nn:‘docutils‘\ \ :kn:‘import‘\ \ :n:‘nodes‘\ \ :kn:‘from‘\ \ :nn:‘docutils.parsers.rst‘\ \ :kn:‘import‘\ \ :n:‘directives‘\ \ :kn:‘from‘\ \ :nn:‘docutils.parsers.rst‘\ \ :kn:‘import‘\ \ :n:‘Directive‘\ \ :kn:‘from‘\ \ :nn:‘docutils.statemachine‘\ \ :kn:‘import‘\ \ :n:‘StringList‘\ \ :c:‘# la directiva es una clase‘\ \ :k:‘class‘\ \ :nc:‘SVGTemplate‘\ \ :p:‘(‘\ \ :n:‘Directive‘\ \ :p:‘):‘\ \ :sd:‘""" The svgt directive"""‘\ \ :c:‘# cuantos argumentos obligatorios tenemos‘\ \ :n:‘required_arguments‘\ \ :o:‘=‘\ \ :mi:‘0‘\ \ :c:‘# cuantos argumentos opcionales‘\ \ :n:‘optional_arguments‘\ \ :o:‘=‘\ \ :mi:‘0‘\ \ :c:‘# si la directiva termina con una linea en blanco‘\ \ :n:‘final_argument_whitespace‘\ \ :o:‘=‘\ \ :bp:‘False‘\ \ :c:‘# funciones de validación para los argumentos‘\ \ :n:‘option_spec‘\ \ :o:‘=‘\ \ :p:‘{}‘\ \ :c:‘# si puede tener mas rst adentro de la directiva‘\ \ :n:‘has_content‘\ \ :o:‘=‘\ \ :bp:‘True‘\ \ :c:‘# método que hace el procesamiento‘\ \ :k:‘def‘\ \ :nf:‘run‘\ \ :p:‘(‘\ \ :bp:‘self‘\ \ :p:‘):‘\ \ :k:‘return‘\ \ :p:‘[]‘\ \ :c:‘# le pone nombre a la directiva y la registra‘\ \ :n:‘directives‘\ \ :o:‘.‘\ \ :n:‘register_directive‘\ \ :p:‘(‘\ \ :s:‘"svgt"‘\ Los parámetros Primero empecemos definiendo un diccionario que relaciona cada nombre de parámetro (los cuales yo defino que son TODOS opcionales) con una función que los valida. Por 7 otra parte dado la estructura que queremos generar de figure posee contenido y la nues- tra también debe poseerlo. \ :kn:‘import‘\ \ :nn:‘json‘\ \ :c:‘# docutils imports‘\ \ :n:‘SPECS‘\ \ :o:‘=‘\