Categoría: python

Condensaciones 0.6

Para empezar el año con novedades, aquí va una nueva versión de Condensaciones, la aplicación de cálculo de parámetros higrotérmicos de cerramientos y que permite comprobar la existencia de condensaciones superficiales o intersticiales.

Esta nueva versión 0.6 incluye como novedades principales:

  • Mejora del rendimiento general para trabajar con mayor fluidez.
  • Inclusión de una barra de condensaciones totales en la zona de información, con cantidades e indicación gráfica de la cantidad condensada en cada periodo.
  • El encabezado indica ahora la localidad y el periodo activo y se ha mejorado la indicación de condensaciones por el color de fondo (verde = sin condensaciones, anaranjado = condensaciones intersticiales o superficiales, rojo = condensaciones intersticiales y superficiales).
  • La gráfica de presiones y temperaturas muestra los resultados del periodo activo, que se puede cambiar en el diálogo de ambientes.
  • Se elimina la gráfica de presiones de vapor incluyendo su información en la de presiones y temperaturas.
  • El color asignado a un material se conserva al cambiar el orden de capas tanto en la lista de capas como en el gráfico de presiones y temperaturas.
  • El informe incluye un histograma de condensaciones acumuladas en cada periodo.
  • La ayuda en HTML está disponible desde el menú del sistema (win32).

Como el aspecto general ha cambiado ligeramente aquí va un pantallazo de la versió 0.6:

Condensaciones - Diagrama de presiones y temperaturas

La aplicación se puede descargar en la página de desarrollo del proyecto.
La documentación, incluyendo manual del usuario y referencia de programación están disponibles aquí.

¡Espero que la disfrutéis!

Condensaciones – nueva versión 0.5.4

Hace ya unos días subí una nueva versión de la aplicación Condensaciones.

Condensaciones es una aplicación que permite realizar el cálculo de los parámetros higrotérmicos de cerramientos y la comprobación de la existencia de condensaciones superficiales o intersticiales.

Condensaciones - Diagrama de presiones y temperaturas

Las novedades principales de la versión actual (0.5.4) respecto a la versión 0.4 son las siguientes:

  • Nueva base de datos de cerramientos en formato .ini.
  • Nueva base de datos de climas en formato .ini.
  • Base de datos de Materiales más compacta.
  • Nueva opción de entrada de climas exteriores según base de datos o manual.
  • Nombre y descripción de cerramientos editables.
  • Es posible añadir, eliminar y mover cerramientos en la base de datos.
  • Es posible guardar cerramientos de la sesión activa.
  • La aplicación se inicia con el primer cerramiento de la base de datos.
  • La lista de capas incluye el color del material que se usa en las gráficas.
  • Muestra localidad/mes seleccionado en encabezado e informe.
  • Indica condensaciones superficiales para el mes de enero s/CTE en el informe.
  • Indica condensaciones intersticiales para todos los meses en el informe.
  • Muestra índice de meses con condensaciones intersticiales en el informe.
  • Indica en amarillo si no se cumplen condiciones CTE en otros meses aunque se cumplan para las condiciones actuales.
  • Representa con relleno rojo la zona de condensaciones, en la gráfica P-T.
  • Salida de informe en navegador HTML.
  • Documentación inicial en HTML (disponible en la web).

La aplicación se puede descargar en la página de desarrollo del proyecto.
La documentación, incluyendo manual del usuario y referencia de programación están disponibles aquí.

Todavía hay muchas cosas que me gustaría mejorar, pero esto avanza a ratos libres…

¡Espero que la disfrutéis!

Simple python calc addin example

OpenOffice calc spreadsheet screenshotThe OpenOffice spreadsheet application, calc, can be extended through plugins to support new functions that can be as easily used in cell formulas as the built-in ones.

Being able to do this using my favourite language, Python, is possible, but not very well documented, so I’ve experimented a bit with it and have come up with a simple example that defines a bunch of new functions that take double and range arguments and return a single value or write back to a defined range. This example can be used as template to write your own plugins and is released under a GPL v2 or greater license.

The example has been developed using OpenOffice 2.4 running on Vista. To build it, you need the OO 2.4 SDK and a MSys environment to comfortably use makefiles and get a decent shell.

The extension file has in it all the needed files to rebuild the example. As the .oxt files are just zipped files you can get them renaming the extension file so it gets a .zip extension and unzipping it.

The makefile has some variables that point to the SDK dir and zip utility that you need to tweak and has the all and install targets build and install the extension.

Addins are composed by:

  • an .idl file to define the interfaces
  • a manifest.xml file to define the extension resources
  • an implementation file

I hope this calc addin example is simple enough to get started. Enjoy!

Click here to download calc addin example: PachiAddin.oxt

Postproceso de capas en planos de CypeCAD

Plano de despiece de pilares en estructura de hormigón armadoEl programa de cálculo de estructuras CypeCAD permite exportar los planos de las estructuras que calcula a archivos DXF para su manejo posteriore en programas de CAD.

El programa usa una serie de capas que corresponden a distintos elementos como textos de armados, tipos de armado, etc. Esta separación es muy prolija y tiene la ventaja de que permite diferenciar muy bien a posteriori a qué función estructural pertenece cada elemento de dibujo.

Sin embargo, la profusión de capas hace poco manejable el dibujo final y es necesario reducirlas a un subconjunto más reducido que, normalmente, se corresponderá también a un criterio personal de dibujo.

Este post explica cómo manejo el cambio de capas a partir de los planos generados en el CypeCAD, y otro día comentaré el criterio de capas de suelo utilizar, ya que lo he estado utilizando varios años y la gente que lo ha probado lo ha adoptado como suyo :).

Volviendo a la gestión de capas de CypeCAD, si bien el programa permite definir a qué capas se deben traducir los distintos elementos, la interfaz para hacerlo es bastante engorrosa, ya que exige recorrer una a una las numerosas capas que incluye por defecto y esta configuración no se puede guardar para poder utilizarla en otra máquina o recuperarla al actualizar la aplicación.

Para automatizar la resolución del problema de unificación y estandarización de capas, genero los planos usando las capas por defecto de CypeCAD y luego utilizo un script que he escrito en Python que traduce sus capas a otras personalizadas.

La traducción entre el nombre de capa original y el deseado se define en un archivo en formato de texto plano llamado capas.txt con una sintaxis muy sencilla:

CIM_COTAS|e.cotas
CIM_CUADRO_ARRANQUE|e.1.gordas
CIM_CUAD_VIG_ATA|e.1.gordas
CIM_CUAD_VIG_CEN|e.1.gordas
CIM_CUAD_ZAPATA|e.1.gordas
CIM_DIB_ARMADOS|e.armado.gordo

Las capas sin la correspondiente capa «traducida» tras la barra vertical no cambian su nombre, por lo que las nuevas capas que puedan ir incorporando en nuevas versiones de la aplicación se mantienen intactas.

Para la ejecución del script es necesaria la instalación del intérprete de Python, y el propio script ofrece información sobre los parámetros que acepta:

$python cambia_capas_cype.py

Quienes usen el programa AutoCAD de AutoDesk, pueden completar la estandarización de capas bien insertando el DXF en un dibjo nuevo iniciado con una plantilla en la que estén definidas las propiedades de las capas, o bien usando la función LAYTRANS. En un futuro es posible que amplie el script para definir las propiedades de las capas en el propio DXF procesado.

Descargar aplicación de cambio de capas para DXF de CypeCAD.

Yay Planet Gnome!

Pygtk splash screenshotThis is my first post after being added to the planet.gnome.org feed, so, thanks to Jeff Waugh for it and to Alberto Ruiz for putting his hackergotchi skills to my service! :).

For those that don’t use to hang on the #pygtk IRC channel, I’ll briefly introduce myself.

My GNOME related activities are mainly tied to the PyGTK project the Python bindings to GTK+, working mostly on keeping the site up-to-date, and give some help on IRC, besides contributing translations and documentation to the project. Thanks to Johan, Gustavo, Kiko and Finlay for helping to get into it and make PyGTK rock.

Besides that, I’m a young architect living in Madrid which some years ago got deeply in love with free software as a hobbyist programmer who was eager to learn.

As Alberto Ruiz already posted and you may already know, we are trying to refactor a bit the www.pygtk.org website, so as to make it easier to find and navigate its contents and keep a bit more focused.

We’d like to help new contributors to get involved in keeping the project rolling. So these are some of the tasks we’d like to slowly achieve, and, as always, any help is much appreciated:

  • Choose the right words for the website key navigational categories.

    The key points here, IMHO, are using simple words, avoid technical terms, being descriptive but terse, concise and precise. Suggestions are welcome :).

    Ideally, we’d like to simplify it, dividing the information into the ‘Know about PyGTK’, ‘Get PyGTK’, ‘Learn’, ‘Participate’ categories, and finally use them as the four entry points for the site contents, similarly to what the RoR folks are doing.

  • Publish the PyGTK FAQ on HTML and PDF formats.

    Now that the PyGTK FAQ lives in the gnome.org wiki, we’d like to have scripts to fetch those contents and generate static HTML and PDF versions from them. It would serve also as a backup measure.

    It’s already possible to get a docbook version from MoinMoin pages, and a docbook to HTML and PDF is already in place for the PyGTK reference and PyGTK tutorial, but it has not been tested for this purpose, and we still miss a (python) script to fetch the FAQ pages and drive the static HTML and PDF generation.

  • Get a small screenshot (200x150px) for each of the apps in the PyGTK application list.

    This is all about writing GUI apps, but we still don’t show what they look like!.

  • Take screenshots for our the introductory pages.

    Besides explaining what PyGTK can do, we should show an attractive bunch of PyGTK apps running on various platforms (win32, OSX and other less common platform screenshots are specially welcome), as being multiplatform, the easy to take language and powerful toolkit are PyGTK’s strong points.

  • Build and document how to create pygtk installers for the win32 platform

    Most people using the website to get PyGTK are using that platform, as ,on GNU/Linux, distros do a great job and interpreted or compiled languages are equally hard to install, but the problem gets harder on platforms without a sensible packaging system that almost exclusively rely on unmanaged installation of disperse binaries. An this last is what Woe32, as the gettext crew calls it, is doing.

    Alberto is doing a incredibly great and superb job to achieve easy distribution of PyGTK (and GTK+) apps, but further help would be very welcome. Work out a gtk+pygtk+py2exe toolchain is something that could be interestng.

  • Write/collect PyGTK articles to cover all skill levels.

    IMHO, we excel in covering basic and advanced skills, but we lack intermediate level documentation. There’s not too much information about application design patterns, model/presentation decoupling, how to write custom widgets or extending GTK+/Gnome using PyGTK… Probably these are hard to explain, as they’re not very detailed or very general concepts, but a mix of subtle criteria and making it all fit, but we shouldn’t avoid trying to get them explained. Some of the articles in the Gnome Journal were great in that respect, and the applications list tries to fill this gap showing examples that may help understand how other programmers do it.

If you feel like giving a shot to any of these, just show up on the #pygtk IRC channel on gimpnet and introduce yourself :).

Programación orientada a objetos en Python

Logo programación orientada a objetos en python

Introducción a la programación orientada a objetos

Este artículo es una introducción a la programación orientada a objetos (POO, o OOP por sus siglas en inglés), uno de los paradigmas de programación estructurada más importante hoy en día.

El artículo usa el lenguaje Python para los distintos ejemplos, y explica la implementación de la POO en ese lenguaje, aunque aborda conceptos generales que son fácilmente trasladables a otros lenguajes.

Los fragmentos de código se señalan usando un estilo de texto diferente (ancho fijo) y, cuando se utiliza el intérprete de python, se prefija cada línea con los símbolos ‘>>>’.

Esta introducción presupone conocimientos básicos de programación y del lenguaje python.
Continuar leyendo «Programación orientada a objetos en Python»

Pascaline – cálculo de la presión de hundimiento en zapatas

cálculo de la presión hundimiento zapata - CTEPascaline, el proyecto que quiere llevar el software libre al cálculo de estructuras, ha avanzado un pequeño paso más estos días con la incorporación de un programa para el cálculo de la presión de hundimiento en zapatas siguiendo la formulación del CTE DB-SE-C.

El 24 de octubre, Alfredo Rodríguez Viescas, ‘Fredo’, envió la implementación inicial a la lista de correo de Pascaline y anteayer subí una versión corregida al repositorio del proyecto.
Continuar leyendo «Pascaline – cálculo de la presión de hundimiento en zapatas»

The Zen of Python

pachi@pachi-portatil:~$ python -i

Python 2.4.4c0 (#2, Jul 30 2006, 15:43:58)
[GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>