| felix | jaime: startlog #redes |
| felix | jaime: startlog #qc |
| fernand0 | bueno |
| fernand0 | vamos allá |
| fernand0 | Hola, |
| fernand0 | |
| fernand0 | hoy tenemos con nosotros a otro veterano. Ha participado en casi todas las |
| fernand0 | ediciones anteriores del congreso. |
| fernand0 | |
| fernand0 | Se trata de Antonio Larrosa de Málaga, |
| fernand0 | España. Es uno de los desarrolladores de KDE y hoy nos va a hablar de |
| fernand0 | "Herramientas de desarrollo de KDE". |
| fernand0 | |
| fernand0 | Es licenciado en matemáticas y representante del proyecto KDE en España. |
| fernand0 | Y si le preguntan mucho al final, igual nos da una noticia interesante ;) |
| fernand0 | |
| fernand0 | Gracias a Antonio por venir a contarnos cosas intersantes como hace siempre |
| fernand0 | y gracias a todos ustedes por acudir a esta conferencia. |
| fernand0 | Como es habitual, la conferencia será en este canal. |
| fernand0 | Si hay traductores, la traducción se hará en #redes |
| fernand0 | Finalmente, si hay preguntas y comentarios, los pueden hacer en #qc |
| fernand0 | |
| fernand0 | antlarr ... |
| antlarr | muchas gracias fernand0 |
| antlarr | y gracias a todos los asistentes por acudir por aquí |
| antlarr | a ver algunas cosas sobre herramientas de desarrollo de KDE |
| antlarr | Aunque hablaré sobre herramientas hechas con KDE |
| antlarr | éstas se pueden usar para desarrollar cualquier tipo de aplicaciones |
| antlarr | de KDE, de GNOME, de consola, abiertas, cerradas, etc |
| antlarr | así que espero que sea del agrado y el interés de todos |
| antlarr | Para empezar (y casi en la totalidad de la charla) hablaré de kdevelop |
| antlarr | Como ya conoceréis la mayoría, KDevelop es el entorno de desarrollo integrado de KDE |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_1.png |
| antlarr | ahí he dejado una foto del entorno |
| antlarr | Al final dejaré todas las fotos en mi página web o en la página web del congreso |
| antlarr | Como veis, está compuesto por distintas áreas |
| antlarr | En la parte izquierda se puede ver el árbol de clases en el caso de que estemos desarrollando una aplicación con un lenguaje orientado a objetos |
| antlarr | Igual que se puede ver la lista de ficheros en el directorio actual, organizados por grupos, |
| antlarr | la lista de marcadores, etc. |
| antlarr | Bueno, tendría que comentar que aunque en las fotos aparecen todos los mensajes del programa en inglés, esto es así porque yo lo uso en inglés, pero está todo traducido al castellano |
| antlarr | para los que quieran usarlo en nuestro idioma |
| antlarr | si nos fijamos en la parte de abajo, vemos que hay pestañas para abrir otras áreas |
| antlarr | como son, la de la salida estandar (stdout) y stderr de la aplicación |
| antlarr | y algunas pestañas para usar herramientas específicas que luego comentaré |
| antlarr | En la parte derecha, vemos que hay una zona de documentación, etc. que luego también comentaré mas detalladamente |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_2.png |
| antlarr | Ahí vemos el diálogo que aparece al crear un nuevo proyecto |
| antlarr | Como veis, se puede programar con KDevelop en multitud de lenguajes y no sólo en C o C++ |
| antlarr | Incluyendo: Java, Python, Pascal, Perl, PHP, Ada, etc. |
| antlarr | Al abrir cada uno de los lenguajes, aparecen más opciones para crear un proyecto con una estructura básica ya hecha, de forma que no haya que programar las cosas básicas de la aplicación |
| antlarr | En el caso de C++, da la opción de desarrollar un proyecto con ClanLib, con ncurses, SDL, etc |
| antlarr | Como veis, algunos apartados como QMake, KDE, GTK son también ramas que se abren |
| antlarr | por ejemplo, al abrir KDE, da la opción de crear una aplicación de KDE normal, o que usa KParts (la arquitectura de componentes de KDE), crear un salvapantallas, un módulo para el Centro de Control de KDE |
| antlarr | un "esclavo de KIO" (ioslave en inglés), etc |
| antlarr | igualmente, al abrir la rama de Proyecto en C, da la opción de crear un proyecto para GNOME, etc |
| antlarr | Como cosa curiosa es que también está preparado para programar proyectos con compiladores cruzados. En la foto se ve que se puede programar para Win32, y en la parte de C, también aparece por ejemplo la opción de desarrollar una aplicación para GameBoy Advance |
| antlarr | En la parte de Embeeded se puede también desarrollar para PDAs (Zaurus, ipaqs, etc.) |
| antlarr | Me preguntan que qué es un "esclavo de KIO" |
| antlarr | KIO es la arquitectura de KDE para entrada/salida de datos, es decir, lo que usan todas las aplicaciones de KDE para leer/escribir ficheros y directorios |
| antlarr | al usar KIO, todas las aplicaciones se abstraen de la forma de acceder a los ficheros, y en vez de guardar la dirección de un fichero como una cadena (típico char *file="/tmp/prueba"), lo que hacen es usar una URL |
| antlarr | y la arquitectura KIO se encarga a través de los "esclavos" de acceder a cualquier protocolo que se haya especificado |
| antlarr | Por ejemplo, si estás editando un fichero con kate, puedes abrir el diálogo de guardar fichero normal estandard, el de toda la vida, y decirle que lo guarde en ftp://mimaquina/pub/incoming/mifichero.txt |
| antlarr | en ese caso, KIO usará el esclavo que "habla" el protocolo ftp para guardar ese fichero |
| antlarr | Volviendo al tema de KDevelop :) |
| antlarr | El crear un proyecto que sea un esclavo de KIO sirve para implementar un protocolo tuyo propio, que automáticamente TODAS las apliaciones de KDE puedan usar |
| antlarr | Ahora mismo por ejemplo, hay módulos o esclavos de KIO para cosas tan dispares como acceder a imágenes de una cámara de fotos que esté conectada al usb, acceder a ficheros de la red emule, (obviamente, http, https, ftp, y el resto de estándares) |
| antlarr | y para mi gusto, de los más útiles, el protocolo "fish" que hace que al ir a fish://usuario@maquina desde cualquier programa de KDE (konqueror por ejemplo) se acceda a esa maquina mediante ssh |
| antlarr | pero bueno, vamos a volver a las herramientas de desarrollo que como veis, KIO solo da tema para una charla completa :) |
| antlarr | Estábamos en la creación de un nuevo proyecto |
| antlarr | Una vez que se le pone el nombre del proyecto, pide el nombre del desarrollador que lo crea y algunos datos fundamentales, como la licencia que va a tener el proyecto y la cabecera que va a haber en los ficheros |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_3.png |
| antlarr | Ahí teneis lo que comentaba de la parte de documentación al lado derecho del entorno |
| antlarr | Como veis, ahi documentación extensa y variada de todos los temas necesarios para cualquier desarrollador |
| antlarr | Obviamente, incluir junto con kdevelop toda la documentación de todos los temas sería una barbaridad porque ocuparía muchísimo y no se tendría actualizado, así que cuando se pulsa para ver la documentación de alguno de esos temas, lo que ocurre es que |
| antlarr | kdevelop muestra la página web oficial de la documentación (usando KIO, por supuesto :) ) |
| antlarr | además, si no se tiene acceso a internet, se puede copiar localmente |
| antlarr | o añadir enlaces a sitios nuevos que hagan falta para nuestro proyecto |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_4.png |
| antlarr | Aquí vemos una de las cosas más interesantes |
| antlarr | Cuando se crea un proyecto nuevo con KDevelop, éste crea un proyecto que usa automake/autoconf para crear los Makefiles necesarios |
| antlarr | como sabréis la mayoría, editar los Makefile.am puede ser bastante rollo si no se tiene mucha práctica (o incluso con práctica), así que hay una pestaña llamada "Automake Manager" que da la posibilidad de editar los makefiles gráficamente |
| antlarr | En esta foto vemos que esto está dividido en dos partes |
| antlarr | arriba, aparecen los directorios que componen el proyecto |
| antlarr | al pulsar en cada uno, vemos el contenido del Makefile (de hecho, el del Makefile.am) de ese directorio |
| antlarr | En este caso, vemos que ese Makefile genera un programa binario llamado kbillar, que está compuesto por esos ficheros cpp |
| antlarr | Además, hay un fichero .desktop |
| antlarr | que cuando se instala sirve para que aparezca una entrada en el menú del escritorio |
| antlarr | Vemos también que hay bastantes iconitos en la parte de arriba de la pestaña de automake |
| antlarr | por ejemplo, el segundo de arriba sirve para generar un nuevo "objetivo" (un nuevo "target") |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_5.png |
| antlarr | ahí se puede ver las objetivos que se pueden hacer: un programa, una librería normal, una librería de libtool, un script, una cabecera, etc |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_6.png |
| antlarr | Esa foto era para que se viera un poco el menú contextual de un objetivo de automake |
| antlarr | como veis, al crear un objetivo se le dice que se quiere crear una librería (de libtool o no), pero no se dice si va a estática o no |
| antlarr | por ejemplo |
| antlarr | eso se dice en el diálogo de opciones de la propia librería |
| antlarr | Además, en ese menú contextual, hay una opción que pone "Make target active" |
| antlarr | esto es útil por si un mismo proyecto genera varios ficheros ejecutables |
| antlarr | para poder indicar por ejemplo, cual es el que queréis depurar cuando se pulse en "depurar" |
| antlarr | Bueno, supongamos ahora que tenéis un proyecto ya creado, y habéis hecho unos ficheros de código fuente en otro ordenador o alguien os lo ha dado para que los reutilicéis |
| antlarr | en ese caso, es útil la opción de añadir ficheros existentes |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_7.png |
| antlarr | Basta con arrastrárlos del listado de directorio de la izquierda a la parte derecha |
| antlarr | Una cosa interesante de la que no he sacado fotos, pero que creo que hay que comentar es la posibilidad de usar KDevelop con un proyecto que ya existe y no fue creado con KDevelop |
| antlarr | en este caso, hay una opción para importar un proyecto existente |
| antlarr | ya use automake/autoconf o incluso Makefiles propios vuestros completamente hechos a mano |
| antlarr | en el primer caso, KDevelop analiza los Makefile.am y da todas las opciones, y en el segundo caso, simplemente quita del interfaz todas las opciones que sirven para modificar los Makefiles y se encarga de no modificarlos automaticamente |
| antlarr | Pasamos a http://developer.kde.org/~larrosa/umeet2004/umeet_8.png |
| antlarr | Vamos a hablar del completado de texto |
| antlarr | aunque antes hay una pregunta |
| antlarr | "antlarr, yo por ejemplo uso gnome y el anjuta no me dá ninguna ventaja frente a trabajo con proyectos externos, por lo cual acabo usando nano con syntaz highlighting y poco más, sin IDE's. quisiera saber si kdevelop soporta algo así cómo simple indexación del código del proyecto y trabajar en él sin tener que importar nada innecesario (como Anjuta con las autotools)" |
| antlarr | efectivamente, sí que lo soporta |
| antlarr | Si usas kdevelop, puedes aprovechar toda la parte de completado de texto (del que ahora hablaré), depuración integrada, documentación a mano, etc |
| antlarr | (sin hablar, de la compilación en el mismo entorno, sin tener que salirte y entrar y tal) |
| damage | in the first case, KDevelop analyzes the Makefile.am and gives all the options, and in the second case, simply it clears of the interface all the options that serve to modify the Makefiles and it is in charge of not modifying them automatically |
| damage | *perdon* |
| antlarr | perdonado :) |
| antlarr | Continuamos hablando entonces del autocompletado |
| antlarr | Antes quizás habría que explicar que KDevelop usa la arquitectura de componentes de KDE para empotrar una componente de Kate (el editor de texto avanzado) dentro del interfaz, y es el que se usa para editar el código fuente |
| antlarr | el editor de texto de por sí, incluye plugins |
| antlarr | que se configuran en el diálogo que se ve en la foto umeet_8 |
| antlarr | uno de esos plugins es el de completado de palabras, y sirve para completar cualquier palabra que aparezca en el mismo fichero |
| antlarr | esto se hace así porque Kate es "simplemente" un editor de textos, y por lo tanto no entiende realmente de "lenguajes de programación" |
| antlarr | por otra parte, KDevelop también tiene un analizador de código fuente bastante avanzado que analiza todo el código fuente de la aplicación y comprende lo que son tipos de datos, clases, métodos de clases, etc |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_18.png |
| antlarr | (sí, hay un pequeño salto) |
| antlarr | Como veis, la diferencia está en que uno es inteligente, y sólo completa cosas que tienen sentido (sea esto bueno o malo) y el otro lo autocompleta todo, pero sólo dentro del mismo fichero |
| antlarr | mi recomendación personal, es que lo configuréis como lo he mostrado en la foto, es decir, desactivando el autocompletado automático del que autocompleta dentro del fichero, y activando todas las opciones del autocompletado específico de C++ |
| antlarr | (o C) |
| antlarr | así, cuando estéis escribiendo "miobjeto." |
| antlarr | automaticamente se abre una pequeña ventana con una lista con los miembros de la clase de miobjeto |
| antlarr | y cuando queráis completar texto por ejemplo dentro de un comentario, podeis usar Ctrl+Espacio para que aparezca la misma ventana, pero con el resto de palabras del fichero |
| antlarr | (en este caso, hay que escribir al menos 2 o 3 letras de la palabra según lo hayáis configurado) |
| antlarr | Pregunta: antlarr: aquí va mi pregunta -> ¿en cualquiera de los lenguajes permite ctrl+espacio? |
| antlarr | Sí |
| antlarr | Ctrl+espacio es una característica del editor de texto (kate), que completa palabras dentro del fichero, no utiliza ningún parseador "inteligente" que diferencie funciones de una clase de las de otra, por ejemplo |
| antlarr | Pregunta: antlarr: inclusive en packages de perl? [el plugin EPIC de eclipse me muestra los métodos de los objetos con ctrl+espacio] |
| antlarr | La verdad es que eso no te lo puedo decir, porque me temo que no he programado nunca en perl "en serio" |
| antlarr | (yo soy más de python :) ) |
| antlarr | así que no sé si traerá alguna forma de autocompletar de forma inteligente en perl |
| antlarr | Bueno, para los programadores de C/C++, una cosa típica (sobre todo dentro de un entorno empresarial) es usar librerías privadas |
| antlarr | no estándares |
| antlarr | por supuesto, todo el mundo quiere que se autocompleten también los métodos de los objetos de clases de esas librerías |
| antlarr | pero no se tiene una copia de las cabeceras de esas librerías dentro de todos los proyectos |
| antlarr | con lo que el analizador de KDevelop no puede encontrarlas |
| antlarr | en principio :) |
| antlarr | Como habréis visto en la última foto, hay un botón "Add Persistant Class Store" |
| antlarr | que al pulsarlo muestra un diálogo: |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_19.png |
| antlarr | Aquí se puede dar un nombre a la librería y darle una serie de directorios de donde KDevelop puede leer las cabeceras, entonces, genera una pequeña base de datos con esa información y permite usar el autocompletado de funciones y clases de esa librería en cualquier proyecto |
| antlarr | Bueno, vamos a seguir por orden con las imágenes |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_9.png |
| antlarr | Ahí simplemente muestro el terminal integrado |
| antlarr | que es bastante útil a veces para no tener que abrir un konsole e ir al directorio donde esté el fichero de código fuente en cuestión |
| antlarr | Seguimos con las opciones para personalizar kdevelop al gusto y estilo de cada programador |
| antlarr | como todos sabemos, practicamente no hay dos programadores en el mundo que usen el mismo estilo de programación, asi que configurar el editor para que automaticamente se ajuste a nuestro gusto puede ser complicado |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_10.png |
| antlarr | aquí vemos se puede configurar el estilo de formateo del código |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_11.png |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_12.png |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_13.png |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_14.png |
| antlarr | muestran los distintos estilos más o menos estándares que existen |
| antlarr | por si directamente se quiere usar uno de ellos |
| antlarr | por ejemplo el que se llama Linux es el que se debe usar en el kernel de linux |
| antlarr | (hablando del kernel, se me olvidó comentar antes como curiosidad que una de las opciones que da al crear un nuevo proyecto es crear un módulo para el kernel) |
| antlarr | Si aun así, no nos gusta ninguno de estos estilos, se puede seleccionar "Definido por el usuario" y especificarlo en las siguientes pestañas: |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_15.png |
| antlarr | Ahí se muestra la eterna lucha entre ¿espacios o tabuladores? |
| antlarr | qué cosas se deben indentar y cuanto |
| antlarr | y en http://developer.kde.org/~larrosa/umeet2004/umeet_16.png |
| antlarr | permite especificar otros parámetros del estilo de cada uno |
| antlarr | en http://developer.kde.org/~larrosa/umeet2004/umeet_17.png |
| antlarr | se pueden ver los plugins que hay activados en kdevelop |
| antlarr | tengo resaltado el de CTags porque además del autocompletado propio de Kate, y el de KDevelop, también se puede usar ctags |
| antlarr | como se puede ver en http://developer.kde.org/~larrosa/umeet2004/umeet_22.png |
| antlarr |
Me dicen que copie de #qc: |
| antlarr | Otro aspecto a configurar es el estilo de nombrar a los métodos que toman o ponen el valor de un atributo de una clase |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_20.png |
| antlarr | Ahí se muestra como automáticamente a partir del nombre de una variable, KDevelop puede obtener automáticamente el nombre de la función que devuelve el valor de esa variable y el nombre de la función que le cambia el valor |
| antlarr | esto sirve para que funcione mejor el diálogo de crear atributos de una clase, u otros sitios donde hay que automatizar estas cosas |
| antlarr | Más cosas curiosas, que además de curiosas son BASTANTE útiles... |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_21.png |
| antlarr | No os ha pasado nunca eso de que os poneis a compilar y se os ha olvidado un ; o un paréntesis y después de compilar un rato teneis que volver a editar, buscar donde está el fallo realmente y probar de nuevo? (porque ya sabéis que los problemas de que faltan ; son bastante escandalosos en el compilador) |
| antlarr | supongo que si alguien dice que no le ha pasado nunca está mintiendo :) |
| antlarr | así que kdevelop tiene una cosa para que no suceda esto ya que avisa cuando encuentra algún problema cambiando el color de la linea, poniendo un icono de "problema" y añadiendo una entrada a la lista de "problemas" |
| antlarr | todo esto de forma completamente automática mientras se está editando el código fuente |
| antlarr | "en tiempo real" |
| antlarr | En esa foto le he quitado el ; de justo antes de los cierres de llave |
| antlarr | para que se viera el problema |
| antlarr | Además, mientras leía el código fuente, encontré un problema que marqué con un comentario (simplemente escribiendo // Fixme blah blah ) para arreglarlo más tarde. Así que KDevelop me avisa diciéndome que hay algo que hay que arreglar |
| antlarr | Igualmente, extrae de la documentación de docbook la lista de "to-do"s (tareas por hacer) |
| antlarr | Bueno, tenía aquí una foto del diálogo de editar opciones de un objetivo de Makefile (un binario en este caso) |
| antlarr | que no me he acordado de poner antes: |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_23.png |
| antlarr | Simplemente para que se vea como se hace que un ejecutable linke con otra librería más aparte de las estándares |
| antlarr | Más cosas interesantes: Las expresiones regulares |
| antlarr | ¿qué hacer cuando hay que depurar una expresión regular? |
| antlarr | es decir, hacer pruebas para ver con qué textos concuerda una expresión regular |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_24.png |
| antlarr | en el menú de herramientas de kdevelop, aparece una herramienta para hacer este tipo de pruebas |
| antlarr | en ese diálogo podemos indicarle qué tipo de expresiones regulares queremos usar (de grep, de egrep, de QRegExp o de KRegExp), la expresión regular, y una cadena te prueba. Y nos dice si concuerda o no y qué subgrupos se obtienen |
| antlarr | (QRegExp y KRegExp son dos clases, de Qt y KDE respectivamente muy útiles para usar expresiones regulares) |
| antlarr | así que se pueden hacer pruebas muy rápidamente y muy fácilmente |
| antlarr | sin tener que editar, compilar, ejecutar, editar, compilar, ejecutar, editar ... etc. |
| antlarr | Además, generalmente todos los programadores con algo de experiencia conocemos las expresiones regulares y podemos escribir la mayoría de las que necesitamos casi sin problemas directamente |
| antlarr | pero si la expresión regular es muy compleja, o simplemente no tenemos experiencia o no conocemos bien las expresiones regulares, podemos usar un editor visual |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_25.png |
| antlarr | El editor de expresiones regulares es una componente estandar de kde que se utiliza en todos (o casi todos) los diálogos de búsqueda de kde (por ejemplo, incluso en el de konqueror) |
| antlarr | seleccionando de los botones de arriba se van añadiendo componentes en el área de trabajo (donde pone "Line Start" en un cuadrado, h ... spaces, lue ) |
| antlarr | como veis, se puede usar de forma totalmente visual, y practicamente no hace falta conocer nada, para obtener una expresión regular aceptable, ya que en la parte de ASCII syntax se escribe la expresión regular en la forma conocida por todos automaticamente |
| antlarr | en este caso, el texto (de la cadena de prueba) que concuerda se subraya, y se pone en rojo con letras un poco más grandes |
| antlarr | pero si con el ratón seleccionamos algunas de las componentes visuales de arriba ( http://developer.kde.org/~larrosa/umeet2004/umeet_26.png ) se puede ver con qué parte del texto concuerdan dichas componentes |
| antlarr | Voy ahora a hablar un poco de herramientas para depurar código y para encontrar errores una vez que lo hemos desarrollado con nuestro kdevelop configurado a nuestro gusto :) |
| antlarr | voy a empezar con una aplicación que no se conoce tanto como se debería: Valgrind |
| antlarr | Si KDevelop ha recibido en el 2004 el primer premio del Linux New York 2004 Conference & Expo a la mejor herramienta de desarrollo, al igual que hizo en el 2002 y 2003 con el Linux New Media Award, Valgrind no se queda atrás |
| antlarr | no tanto en premios (ya que se está haciendo conocido poco a poco) sino en usuarios |
| antlarr | Usándolo practicamente todos los proyectos de software libre (OpenOffice, KDE, GNOME, Mozilla, MySQL, PostgreSQL, etc.) e incluso la NASA lo ha usado para depurar el "Mars Exploration Rover" |
| antlarr | o el CERN |
| antlarr | lo más curioso es que incluso se ha utilizado para depurar juegos como el Unreal Tournament 2003 y 2004, Medal of Honour, o el Yahoo! Messenger |
| antlarr | Una vez dadas esas credenciales, explico lo que es :) |
| antlarr | Basicamente, es una máquina virtual, que ejecuta el binario que se quiera depurar internamente y muestra problemas que encuentre, analizando cada uno de los comandos que ejecuta |
| antlarr | El uso básico que se le da es para encontrar problemas de memoria, ya sea, de pérdida de memoria, de escritura en zonas de memoria en las que no debería escribir, etc |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_27.png |
| antlarr | Ahí se ve la integración de kdevelop con valgrind |
| antlarr | he hecho un programa muy simple que simplemente llama a la función f |
| antlarr | que aparece completa en esa foto |
| antlarr | y le he pasado valgrind usando una entrada del menú "Debug" |
| antlarr | Como veis, automaticamente ha dicho que hay una "escritura inválida de tamaño 1 en la función f, linea 37 de ese fichero |
| antlarr | ¿alguien ve donde está el problema? |
| antlarr | efectivamente, hemos reservado 5 caracteres, y en el bucle for estamos iterando desde el 0 hasta el 5, es decir 6 caracteres, con lo que la última iteración del bucle es incorrecta |
| antlarr | Si vamos para abajo en la pestaña de valgrind vemos más cosas todavía |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_29.png |
| antlarr | Nos dice que hay 5 byes definitivamente perdidos en un sólo bloque |
| antlarr | es decir, que la aplicación ha terminado y nadie ha liberado esos 5 bytes |
| antlarr | en este caso, no nos puede decir donde se nos ha olvidado liberarlos, porque podría ser en infinidad de sitios, pero sí que nos dice donde se ha hecho la reserva de esos 5 bytes |
| antlarr | para que nosotros miremos donde debería liberarse esa memoria, y comprobemos que lo hace |
| antlarr | Nos vamos entonces a http://developer.kde.org/~larrosa/umeet2004/umeet_28.png |
| antlarr | para ver rapidamente el diálogo de ejecución de valgrind |
| antlarr | vemos que se pueden poner algunos de los parámetros automaticamente simplemente marcando checkboxes lo que lo hace mucho más fácil de usar |
| antlarr | Como he dicho antes, valgrind detecta "problemas" al ejecutar un código, pero ¿qué se entiende por problemas? |
| antlarr | eso lo define la herramienta de valgrind que se le diga que use. En este caso le he dicho que use la herramienta memcheck que hace las comprobaciones de memoria |
| antlarr | pero hay algunas otras igualmente interesantes |
| antlarr | por ejemplo, para la gente que use programación con threads/hebras/hilos o como cada uno quiera llamarlas, existe la posibilidad de usar la herramiente helgrind para depurar accesos concurrentes a memoria |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_30.png |
| antlarr | Aquí he ejecutado valgrind --tool=helgrind desde el konsole integrado en kdevelop |
| antlarr | igual que antes es un simple programa que llama a la función h que está completa en la foto |
| antlarr | No entraré mucho en detalles por si no todos están acostumbrados a usar threads, pero basicamente lo que hace el programa es crear un thread, que incrementa el valor de una variable global, un segundo después, crea otro thread que vuelve a incrementar la variable y luego cierra los dos threads |
| antlarr | valgrind en este caso avisa de que es posible que haya una condición de carrera escribiendo en esa variable |
| antlarr | ¿no es increible? |
| antlarr | no avisa sólo en el caso de que en esta ejecución del programa se haya producido un solapamiento de los dos threads intentando incrementar la variable a la vez, sino que avisa que "se puede dar el caso porque no hay un mutex que haya protegido el acceso a esa varible entre el acceso de los dos threads" |
| antlarr | Otra herramienta muy interesante es callgrind |
| antlarr | callgrind se usa para analizar el tiempo de proceso de cada función del programa |
| antlarr | la salida se puede considerar como bastante criptográfica para un ser humano |
| antlarr | así que se usa siempre junto a una interfaz gráfica llamada kcachegrind |
| antlarr | podeis ver fotos en http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindShot |
| antlarr | la verdad es que estoy viendo que esas fotos son algo antiguas, con lo que recomiento bajarlo y usarlo en vivo |
| antlarr | Vamos a ver la foto de http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindShot2 |
| antlarr | En la parte de la izquierda se ve (regular, y si tenéis buena vista) cada una de las funciones, y el tiempo de proceso |
| antlarr | que se ha llevado de CPU |
| antlarr | pero lo ma? interesante es la parte derecha |
| antlarr | pero lo más interesante es la parte derecha |
| antlarr | que es igual que la parte izquierda/abajo de http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindShot3 |
| antlarr | ahí se ven las funciones del programa representadas con rectángulos, y el tiempo de cada función representado en el área ocupada |
| antlarr | igualmente, si una función A llama a una función B, el rectángulo de B aparece dentro del rectángulo de A |
| antlarr | así se ve de una forma completamente intuitiva en qué funciones del programa hay que invertir más para optimizarlas |
| antlarr | Como curiosidad que siempre cuento en estos casos, es que en el congreso de desarrolladores de KDE del año pasado (2003), se vió que el linkador (el ld estandar de gnu) tardaba mucho en linkar las aplicaciones de KDE, así que entre varios desarrolladores de KDE y GCC usaron kcachegrind para ver la salida de callgrind y vieron que había una función que había que optimizar claramente |
| antlarr | la optimizaron e hicieron el linkado casi 12 veces más rápido! |
| antlarr | Ya que estamos en esta última foto, es también interesante la gráfica de la derecha, donde se ve el flujo de llamadas entre funciones también de forma intuitiva |
| antlarr | aparte de para ver por donde se va yendo el tiempo de CPU, yo he usado eso a veces para comprender mejor el funcionamiento de un programa en el que nunca he trabajado antes |
| antlarr | ya que se ve claramente qué funciones llaman a qué funciones |
| antlarr | Volviendo a KDevelop, vamos a hablar del depurador |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_31.png |
| antlarr | Ahí he depurado el primer ejemplo de valgrind |
| antlarr | por un lado he abierto la pestaña de visor de variables |
| antlarr | que muestra automáticamente las variables locales del contexto que estémos depurando, y aparte se le pueden añadir variables en general a observar |
| antlarr | en la parte de abajo, he abierto la pestaña de "Desensamblado" |
| antlarr | que muestra el código fuente en ensamblador |
| antlarr | que ha generado el compilador y que se está ejecutando |
| antlarr | igual que se puede ir ejecutando el programa linea a linea con la posibilidad de entrar o no a las llamadas de funciones |
| antlarr | también se puede ejecutar instrucción de ensamblador a instrucción de ensamblador |
| antlarr | con la posibilidad de entrar dentro de los "call" o no |
| antlarr | además, en cada linea (o instrucción) que se ejecuta, se marca en rojo el valor de la variable que haya cambiado su valor (si ha cambiado alguna) |
| antlarr | en este caso, por ejemplo, acabo de pasar el incl que incrementa eax (es decir "i" ) y por eso está el 3 en ese color |
| antlarr | también se puede ver el "Frame Stack" (pila de llamadas) |
| antlarr | o abriendo la pestaña GDB, se puede ver la salida del gdb (que se usa internamente) e incluso usarlo como si se hubiera ejecutado en un terminal |
| antlarr | Si os habéis fijado una de las pestañas de abajo pone "Diff" eso sirve para ver la salida de un diff de forma gráfica, ya que empotra una componente de kompare o de kdiffpart3 (dos aplicaciones de KDE para ver diffs) |
| antlarr | en vez de enseñar el kompare empotrado, he puesto algunas fotos de la aplicación en sí |
| antlarr | pero podeis imaginaros que la estais viendo integrada, dentro de kdevelop si quereis porque es exactamente igual :) |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/kompare_01.png |
| antlarr |
Pregunta: |
| antlarr | Perdón, llevas razón en que debería haberlo explicado |
| antlarr | diff es un programa de consola que analiza dos ficheros y muestra las diferencias entre ambos |
| antlarr | es decir, permite ver diferencias entre ficheros |
| antlarr | generalmente se utiliza para ver las diferencias entre dos versiones del mismo fichero, por ejemplo, la de hace una semana, y la de ahora |
| antlarr | la salida del programa es muy atractiva si consideramos que en otro caso, tendríamos que ir leyendo linea a linea los dos ficheros y comparando a ojo |
| antlarr | pero si alguien no tiene mucha experiencia puede ser un poco críptica |
| antlarr | para ayudar en eso, está kompare |
| antlarr | que analiza la salida de diff (un fichero diff) y la muestra como esa foto de antes |
| antlarr | como veis es bastante intuitiva |
| antlarr | y se ve rapidamente qué lineas se han borrado, cuales hay nuevas, qué lineas se han modificado y (muy importante, ya que sólo con diff no se puede hacer esto): qué ha cambiado dentro de una linea |
| antlarr | Ahora, supongo que todos tenéis curl, así que id a un directorio vacío y ejecutad: |
| antlarr | curl -O http://developer.kde.org/~larrosa/umeet2004/kompare_[01-14].png |
| antlarr | para bajar las 14 imágenes que he puesto de kompare |
| antlarr | Ahora, si usais mplayer podeis hacer mplayer mf://*.png |
| antlarr | para ver una animación de como se se adaptan las lineas al mover la barra de scroll para ver el fichero |
| antlarr | y sus diferencias |
| antlarr | si no, podéis ir pasándolas una a una |
| antlarr | Como he comentado, hay otro programa muy parecido que se llama kdiffpart3 |
| antlarr | kdiffpart3 no es tan altamente visual como este (aunque también lo es bastante) |
| antlarr | pero en mi opinión tiene como ventajas que hace MUY fácil el mezclar cambios entre las dos versiones distintas de un fichero |
| antlarr | y además, permite incluso hacer comparaciones entre 3 ficheros distintos |
| antlarr | Hmmm, perdón, lo he llamado Kdiffpart3, pero el programa se llama kdiff3, kdiffpart3 es la componente de KParts que kdiff3 provée |
| antlarr | Y creo que voy a ir acabando por ahora |
| MJesus | estamos encantados ! |
| antlarr | hay muchas cosas más interesantes, como muchas opciones de kdevelop que se me han olvidado, pero eso lo dejo para que cada uno las encuentre en su casa/trabajo :) |
| antlarr | además, se podría hablar de kdialog y kommander para hacer desarrollo MUY rápido de aplicaciones en lenguajes de script |
| antlarr | dcop |
| antlarr | etc |
| antlarr | pero quizás dejarlo mejor para otra charla |
| antlarr | ahora, si tenéis alguna pregunta o duda, podemos quedarnos un rato de tertulia |
| antlarr | si no os habéis quedado dormidos todos, claro ;-) |
| antlarr |
|
| antlarr | Yo (afortunadamente :) ) no he usado mucho esto, pero te explico lo que sé |
| antlarr | hay varias formas de desarrollar aplicaciones que funcionen en windows con kdevelop |
| antlarr | lo que yo haría, es hacer una aplicación que use Qt, esa aplicación podrías desarrollarla en linux, y funcionaría tanto en windows, como en linux o MacOS |
| antlarr | (e incluso PDAs) |
| antlarr | la opción que yo comentaba antes, es elegir la opción de usar un compilador cruzado, en este caso sé que se usa MingW para compilar desde linux aplicaciones de win32 |
| antlarr | pero me temo que te puedo decir poco más |
| antlarr | eso sí, quizás te sería interesante saber que en los últimos meses se ha desarrollado bastante el porte de las librerías de KDE a windows (nativamente), y el asunto está bastante avanzado |
| antlarr | ya se pueden ejecutar algunas aplicaciones de KOffice de forma completamente nativa en windows |
| antlarr | y la idea es poder ejecutar konqueror, kontact y kopete (las aplicaciones más básicas) en windows en poco tiempo |
| antlarr |
|
| antlarr | (usando automake) |
| antlarr | sin problemas |
| antlarr | se puede importar en kdevelop como un proyecto basado en automake cualquiera |
| antlarr | kdevelop analizará los ficheros de automake, y podrás usar el automake manager para modificarlos, etc |
| antlarr | He añadido una foto nueva, para comentar algo que creo que puede ser bastante interesante |
| antlarr | y que sería una lástima que no comentara |
| antlarr | http://developer.kde.org/~larrosa/umeet2004/umeet_32.png |
| antlarr | Además, así termino con una potencia de 2 :) |
| antlarr | Cuando se desarrolla una aplicación de KDE |
| antlarr | KDevelop se puede usar para hacer el interfaz gráfico de la aplicación visualmente |
| antlarr | Si alguien está interesado en aprender a usar KDevelop para hacer aplicaciones con este diseñador de interfaces integrado, le remito a mi tutorial de desarrollo visual: |
| antlarr | http://developer.kde.org/~larrosa/visualtutorial/ |
| antlarr | ahí está en inglés y español |
| antlarr | [guitarra] bueno, quería pedirte que nos contaras algo de tu experiencia profesional usando kdevelop |
| antlarr | Yo de siempre he usado vi para desarrollar |
| antlarr | sobre todo porque es rápido de ejecutar en cualquier directorio para editar ficheros sueltos |
| antlarr | pero desde que ha salido kdevelop 2.x y sobre todo ahora con la versión 3.x, lo estoy usando en más y más sitios. |
| antlarr | Por ejemplo, en mi trabajo, principalmente estoy desarrollando uno o dos proyectos |
| antlarr | así que es mucho más cómodo usar kdevelop donde se tiene todo lo relacionado con un proyecto u otro a mano |
| antlarr | además, el poder poner bookmarks a distinta documentación "no estandar" igual que el poder añadir autocompletado de librerías externas, es algo bastante útil |
| antlarr | Bueno, pues si no hay más comentarios, creo que podemos dar por concluida la charla |
| antlarr | Gracias por vuestra atención durante estas 3 horas |
| antlarr | Si teneis alguna duda, mi dirección es larrosa_at_kde org |
| antlarr | hasta pronto |
| damage | clap clap clap clap clap clap clap |
| damage | clap clap clap clap clap clap clap |
| damage | clap clap clap clap clap clap clap |
| damage | clap clap clap clap clap clap clap |
| antlarr | gracias :) |
| felipe | clap clap clap clap clap clap clap clap |
| elkrammer | ACTION aplaude y agradece :) |
| felipe | clap clap clap clap clap clap clap clap |
| felipe | felicitaciones antlarr |
| HnZeKtO | antlarr: woof woof woof woof |
| damage | exelente :) |
| HnZeKtO | antlarr: que pesao eres illo |
| antlarr | :) gracias |
| HnZeKtO | 3 horas dale que te pego |
| antlarr | jeje, lo que hace la confianza ;-) |
| HnZeKtO | aaaaaaaro |
| HnZeKtO | habrá alguien más despierto? XD |
| trulux | CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| trulux | CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| trulux | CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| trulux | CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| trulux | CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| trulux | CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| trulux | CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| trulux | CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| trulux | CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| trulux | YO ME PASOOO A KDEEE |
| trulux | ;D |
| antlarr | :-D |
| HnZeKtO | trulux: ah pero no lo usabas? |
| genkaos | muy buena la charla, enhorabuena antlarr |
| HnZeKtO | trulux: intruder!! |
| trulux | HnZeKtO, No Proactive IDS found, intruder stills saying CLAP CLAP CLAP |
| antlarr | gracias genkaos |
| antlarr | bueno, me recuerdan que diga la "sorpresa" que iba a dar antes |
| azulema | antlarr: interesante tu charla a pesar de las 3 horas y media |
| antlarr | sólo era comentar que en KDE se hacen todos los años una reunión de desarrolladores de todo el mundo y conferencias para usuarios/desarrolladores. Para el 2005 se está barajando la posibilidad de hacerlo en Málaga o Brasil |
| antlarr | pero personalmente veo bastante probable que se haga en España |
| antlarr | gracias azulema |
| elkrammer | antlarr: akademy? |
| antlarr | no hay nada oficial todavía, pero como digo, personalmente lo veo bastante probable |
| antlarr | elkrammer: exacto |
| antlarr | la "akademy 2005" |
| HnZeKtO | así que en agosto del año que viene os esperamos en la feria de málaga |
| HnZeKtO | que digaaaaaa en la akademy |
| antlarr | jajaja |
| trulux | antlarr, con el melenas y sus amigos |
| trulux | XD |
| HnZeKtO | trulux: el melenas es sevillano! |
| elkrammer | antlarr: al ser la mayor parte de los programadores de kde de alemania, tenia entendido que casi siempre se hace alli, o a sus alrededores... creo que malaga queda bastante alejado de alemania ;) |
| antlarr | sí, de ahí la novedad :) |
| HnZeKtO | elkrammer: pues imagínate brasil.... |
| trulux | señoores, haaa llegaaado el meleeenaaaas, elMelenas dice hola a la audiencia, elMelenas sacude el pelo, los que van a usar KDE te salutant |
| trulux | ;) |
| elkrammer | HnZeKtO: jejeje |
| antlarr | hasta ahora siempre se ha hecho en alemania o cerca, pero para el año que viene se quiere hacer fuera, sólo queda elegir el sitio |
| guinsel | si eso ayuda a que las distribuciones de las comunidades utonomas se pasen a KDE :-) |
| antlarr | guinsel: a ver, a ver :) |
| HnZeKtO | ejem, distribuciones autónomas... debian+gnome... no me tiréis de la lengua.... |
| antlarr | ACTION tira |
| guinsel | una pregunta, antes has nombrado que kontact se esta portando a windows, eso quiere decir que el kmail, knode y familia funcionaran en win? |
| antlarr | bueno, realmente el portar kontact todavía no se ha empezado siquiera, se quiere acabar primero con las librerías |
| antlarr | y personalmente pienso que konqueror es mucho más interesante |
| HnZeKtO | antlarr: qt-win gpl? |
| elkrammer | guinsel: kontact a windows? no estoy seguro, pero lo que si se, es que se estan portando las librerias de kde (kdelibs) a win32 hace algo mas de 3 años |
| antlarr | HnZeKtO: qt/x11 (gpl) funcionando en windows :) |
| HnZeKtO | antlarr: bajo cygwin? |
| antlarr | si |
| antlarr | eso creo |
| guinsel | elelkrammer, si eso lo sabia pero como me ha parecido leer lo de kontact me habia emocionado |
| antlarr | elkrammer: bueno, la cosa es que antes era un desarrollo paralelo |
| guinsel | el kvirc hace no se qu emovida con la licencia para utilizar las qt en windows |
| antlarr | desde hace unos meses los cambios denecesarios para que compile en windows están en el cvs |
| elkrammer | antlarr: tu leiste el articulo de aaron seigo sobre que opinaba respecto a portar aplicaciones de codigo abierto a windows? |
| antlarr | uy, "enecesarios" :) |
| guinsel | :-) |
| antlarr | sí, conozco su opinión |
| guinsel | tengo los dedos de la mano gordos |
| elkrammer | antlarr: yo estoy totalmente de acuerdo con el |
| antlarr | yo estaba de acuerdo con él hace unos años |
| antlarr | pero últimamente pienso que para que el usuario "de a pie" se cambie a linux, hay que hacerle los cambios poco a poco |
| antlarr | yo tengo amigos que usan windows, que de pronto se han dado cuenta que usan Firefox, Psi, Thunderbird... y me han dicho "ya uso más software libre que de MS", así que incluso ellos mismos me han dicho "ahora no me importaría pasarme a linux, porque como voy a seguir usando lo mismo..." |
| trulux | antlarr, el problema viene que si se lo cambias y no se lo dices puede que ni se entere |
| trulux | la ignorancia provoca miedo |
| trulux | mejor que no tengan ni idea y que lo usen sin saverlo |
| trulux | ejemplo: mi madre y su portatil |
| trulux | le puse mandrake, anda que no es fácil ni nada la distro, y arrancó y él metió sus fotos de la cámara digital sin problemas |
| trulux | no se dió cuenta hasta después |
| trulux | la gente usa un ordenador y no un so |
| trulux | es la pura realidad |
| trulux | la gente compra un "pc" y no un so + un "pc" |
| trulux | la gente usa el word y no un procesador de textos, etc |
| trulux | la cruda realidad |
| antlarr | eso sí es verdad |
| antlarr | aunque todavía no he encontrado a nadie que haya usado OpenOffice y diga que no se adapta bien y prefiere volverse a word |
| trulux | ya ni hablar de usar kde o gnome |
| elkrammer | alguien guardo esta charla en algun .log o algo? |
| trulux | por eso redhat hizo su bluecurve o algo así |
| antlarr | elkrammer: sí, la están guardando |
| elkrammer | genial :) |
| trulux | por otro lado, la gente no habla de actualizar con un parche de seguridad |
| trulux | la gente habla de lo que le revienta de verdad o de lo que aparece en TV o en los programas de radio típicos con un embajador de M$ soltando chorradas a diestro y siniestro |
| trulux | "hoy vamos a ver como desactivar el asistente inteligente de MSOffice" |
| trulux | "ups, no se puede, me dicen de dirección que pasemos a otro tema" |
| trulux | ... |
| trulux | a todo esto |
| trulux | empiezo ya la charla? |
| antlarr | ¿a qué hora era la tuya? |
| antlarr | no era a las 10 ? |
| trulux | a las 20 GMT |
| trulux | es decir |
| trulux | en 20 minutos |
| antlarr | ah |
| elkrammer | trulux: sobre que es tu charla? |
The Organizing Comittee
