Archive for November, 2006
November 27, 2006 at 22:18 · Filed under Libros
Recientemente acabé con él. Me ha costado, y no por mala prosa, por que no está en absoluto mal escrito, aunque tampoco es de esos libros “amigables” con los que te dan ganas de llamar al autor e invitarle a unas cerves.
El libro es completo, son unas 450 páginas hablando de GNU Emacs. Desde cosas sencillas: cómo abrir un archivo, manejo de buffers, manejo de marcos y de ventanas, pasando por el uso de algunos de los complementos más conocidos de Emacs como dired, la agenda, el modo de dibujo. Hasta las customización en Emacs Lisp del editor.
Obivamente no es un libro de Lisp, ni de Emacs Lisp, pero algunas nociones sí que da. Muestra el enorme soporte de Emacs para la programación, en multitud de lenguajes (Java, perl, C, C++, Lisp, etc.), así como el soporte para escritura de textos, por ejemplo en LaTeX, o por ejemplo en DocBook o en XHTML.
Entre sus varios autores está Eric S. Raymond, y que yo sepa aún no hay traducción al castellano. Pero los de Anaya Multimedia podían tirarse el rollo, ya que han traducido otros tantos también de O’Reilly.
Learning GNU Emacs: Tabla de Contenidos
Para acabar sólo decir que me parece una buena forma de meterse con Emacs. Tenerlo a mano siempre que se vayamos a programar algo o a escribir documentación con Emacs es una buena forma de proceder.
Fácilmente en el eMule podáis encontrarlo, por si queréis echarle un vistazo. Y lo que también podéis encontrar en el eMule son los vídeos de la charla que dio Marchesi en el Kaslab, buscad “marchesi”, o “editor wars” p.ej.;
November 26, 2006 at 15:52 · Filed under C, Sistemas operativos
¿Cómo saber si existe un proceso con un PID determinado? ¿existe algún proceso con el pid 16547?
Se me ocurrieron diferentes formas, algunas poco portables, en otras presentaba dudas, así que pregunté en varias listas de correo.
Y el resultado es este programita en C donde se presentan dos formas programadas (y que funcionan) y comento más o menos cómo funcionan, así como la gente que me ha dado ideas y qué ideas me han dado: existe_pid.c;
Por cierto, gracias a todos los que colaborásteis con este tema.
November 25, 2006 at 16:57 · Filed under Lisp
Siguiendo la idea de MD con Python de que quien enseña aprende dos veces voy a hablar un poco de Lisp, más que nada para ir comentando lo que voy aprendiendo. De momento, hablaré durante unos párrafos sobre los inicios de Lisp y qué lo caracteriza.
Lisp es un lenguaje ideado desde el verano de 1956 hasta el de 1958 e implementado a partir de ese año por John McCarthy. Obtuvo sus ideas tras haberse centrado durante toda la década de los 50 en los trabajos de Alonzo Church[1], en especial en el cálculo lambda. A lo largo de su carrera se dedicó mayoritariamente a la inteligencia artificial, por lo que el lenguaje quedó muy ligado a esos entornos académicos.
Es un lenguaje declarativo, a diferencia de lenguajes imperativos como C, Pascal o Basic, o los orientados a objetos como Java, Smalltalk, C# o C++, que son los que clásicamente son conocidos por todos los informáticos y los [únicos] que se enseñan en las carreras universitarias o en los módulos de formación profesional (al menos los que yo conozco). En cuanto a historia de los lenguajes de programación: es el segundo lenguaje de alto nivel y el primero declarativo, posterior a Fortran que data de noviembre de 1954 cuyo primer manual salió en 1956.
Los lenguajes declarativos, a diferencia de los imperativos requieren que uno exprese qué es lo que quiere conseguir, y no cómo lo quiere conseguir. El primer acercamiento que he tenido en la carrera a los lenguajes declarativos ha sido en la asignatura de Diseño de Bases de Datos donde entre los lenguajes de manipulación de datos (DML, en inglés, frente a los DDL: lenguajes de definición de datos) que se utilizan en los sistemas gestores de bases de datos (SGDB) a nivel histórico diferenciamos entre los procedurales de los primeros sistemas y los declarativos (como p.ej. SQL) de los sistemas actuales.
SQL como lenguaje declarativo que es no requiere indicarle al SGBD de dónde tiene que tomar los datos, sino directamente qué datos debe tomar:
SELECT * FROM alumnos WHERE nombre=’pepito’;
En esa sentencia SQL observamos que se están pidiendo todas las tuplas de la relación alumnos cuyo atributo llamado nombre es igual a pepito. No se indica en nigún momento a qué fichero debe ir el SGBD a buscar tales tuplas, ni en dónde se almacenan las tablas, si en un disco duro o en otro, en un ordenador o en otro, en un sector o en otro, etc. Eso es trabajo para el SGBD[2].
Posteriormente se han desarrollado un gran número de dialectos de Lisp, a partir del dialecto original, como p.ej. el Emacs Lisp, el Common Lisp, GNU Common Lisp o Scheme. GNU Emacs es un potente editor de texto con un núcleo escrito en C y un gran número de extensiones escritas en su propio dialecto de Lisp (el Emacs Lisp, obviamente), y es habitual que sus usuarios tengan cierta relación con el lisp que allí se usa ya que permite un alto nivel de configurabilidad del procesador de textos, ya sea para programar en una gran variedad de lenguajes, para llevar una agenda, para escribir documentación en LaTex, DocBook, XHTML o texto plano, entre otros muchos usos.
Indica Eric S. Raymond en su ensayo Cómo llegar a ser un hacker, al igual que mucha otra gente (a decir verdad casi todos los que han aprendido Lisp), que aprender Lisp otorga una nueva forma muy superior de ver las cosas, prepara la mente para enfocar los problemas computacionales desde otro ángulo, y en general, aunque Lisp no se vaya a usar en la vida real, es conveniente aprenderlo para ser un buen programador. Comentarios similares se pueden leer de Paul Graham[3].
Lisp viene de List Processor, y parte de la magia del lenguaje viene de que trata como una lista tanto el código como los datos. Para lisp no son cosas diferentes, puedes trabajar con un cacho de código como si fueran datos con los que tratar y modificar, lo que facilita la metaprogramación. De hecho, en lisp sólo hay dos tipos de datos: los átomos y las listas (listas de átomos o de otras listas), lo que entre otras cosas facilita bastante el desarrollo de intérpretes de lisp.
Bibliografía:
- La nueva mente del emperador, Roger Penrose
- Fundamentos de Bases de Datos, Silberschatz, A., Korth, H. F., Sudarshan, S.; McGraw-Hill; 2006
- Hacker and Painters, Paul Graham
November 25, 2006 at 16:36 · Filed under Sistemas operativos
Esta mañana he tenido oportunidad de enredar un poquito en una estación de trabajo con IRIX 6.5, y a cuenta de ello ando rebuscando información sobre IRIX.
La máquina en cuestión era un MIPS R10000, que al igual que IRIX lo fabricaba Silicon Graphics (SGI). Que yo sepa tenía un único microprocesador, pero no lo aseguraría, al igual que tampoco sé de qué cantidad de memoria disponía.
El MIPS R10000 salió al mercado en 1995, y tenía serias mejoras frente al R8000, que era el anterior modelo. Tenía dos caches L1 de 32Kb. , también era superescalar y contaba con ejecución fuera de orden (esto no sé lo que es, pero seguro que es muy bueno). Corría a 200 Mhz. Por aquella época, mis colegas del colegio se andaban comprando los Pentium a 133 Mhz. con 32 Mb. de RAM, y aunque el pentium también es superescalar dudo que alcanzara los 110 MIPS que alcanza éste.
Silicon Graphics ha venido desarrollando IRIX desde mediados de los años 80 (incluso en 1981 ya había algo) para sus estaciones de trabajo, si la información que he consultado es correcta. Al igual que las estaciones que ha estado fabricando (MIPS de 32 y 64 bits) tiene un gran potencial para el trabajo con gráficos 3D, por lo que se ha utilizado en animación y representación de datos científicos, además de ser uno de los primeros sabores de Unix en contar con un interfaz gráfico incorporado.
El sistema operativo es un System V (rel. 4) con algunas extensiones BSD, cumple actualmente UNIX95 y POSIX. Por supuesto, es monolítico. Y que yo sepa, sólo está para arquitetura MIPS (aunque antes de que SGI adiquiriera MIPS Computer Systems se desarrollaba para el Motorola 68k). El sistema de ficheros de serie es un XFS, desde hace unos pocos años disponible también en Linux.
La última versión publicada es la 6.5, que vio la luz en mayo de 1998, y desde entonces ha recibido distintas mejoras leves, dando lugar a revisiones: 6.5.1m, 6.5.17, 6.5.28, etc. Cabe destacar la 6.5.22 a partir de la cual el desarrollo se dividió en dos ramas, la maintenance, y la feature, que se corresponden respectivamente con las ramas estable y desarrollo de otros productos (la x86 y la ~x86 de Gentoo GNU/Linux, p.ej.). Y precisamente hasta esa versión se puede descargar uno gratuitamente de la web. Las versiones posteriores requieren un contrato de mantenimiento por parte de SGI. La última versión a la fecha en que se escribió este artículo era la 6.5.30.
El 6 de septiembre de 2006 SGI declaró sus intenciones de dejar de dotar sus estaciones de trabajo con IRIX a partir de diciembre de 2006 para pasarse a Linux. No obstante, seguirá dando soporte hasta 2013.
La máquina en la que he trabajado tenía también instaladas algunas herramientas GNU, como por ejemplo el Emacs y el GCC (aparte de otro compilador de C, que debía ser el de SGI). Y de velocidad: unos 110 MIPS, según el test de Whetstone, frente a los 200 MIPS que aproximadamente he conseguido con un Pentium II a 300 Mhz (¿de 1998?).
He de destacar la presencia de /proc, con un formato totalmente distinto al de Linux. Éste estaba poblado por ficheros con nombre 0000[0-9]+ (expresión regular: 00001, 00002956, y de ese tipo los demás), accesibles sólo algunos de ellos. Intuyo que serían referencias a los PIDs de mis procesos, y que sólo podría acceder a los de mis procesos, y no los de otros usuarios, aunque daba un I/O error al leerlos. Me sorprendieron los PIDs de los procesos que pueden llegar a ser grandes (donde grande significa mayor de 65535, del orden de 100 y pico mil).
El fichero /etc/passwd seguía el modelo antiguo, ese de guardar allí mismo los password encriptados con crypt(). Ni MD5, ni /etc/shadow. Los ejecutables eran ELF. Las opciones para los programas (el -lah en ls -lah) coincidían con las de GNU/Linux (cosa que no comparte con el Solaris 8 que conozco). Y el manual andaba un poco escaso.
Fuentes:
- Wikipedia en inglés
- Wikipedia en castellano
- Página de SGI para IRIX
- Datasheet con las capacidades de IRIX
November 15, 2006 at 17:38 · Filed under Lenguajes de Programación
Hace ya mucho que había oído sobre XML-RPC, pero quitando lo de XML y lo de RPC no sabía exactamente de qué iba. Así que casualidades de la vida, encontré el XML-RPC Howto, y le he pegado una leída esta mañana en lo que esperaba a un personaje.
El XML como sabréis es un lenguaje de marcas, subconjunto de SGML (algo menos potente y sobre todo más sencillito de usar), utilizado para almacenar o transferir datos.
Y RPC es Remote Procedure Call: Hacer uso de funciones que corren en otras maquinas. Por ejemplo, si yo hago una función que deba de calcular la media de las notas de los alumnos tomadas de una base de datos dada, podría programar por un lado la función que saca los datos de la base de datos y por otro lado la función que calcula que llama a la función que saca los datos y que luego calcula la media. Esta última función podría ejecutarse en una máquina y llamar a la que extrae los datos que se encuentra en otra máquina:
funcion media(lista de alumnos)
{
lista_notas=saca_notas(lista de alumnos);
i=suma=0;
por cada nota de lista_notas {
suma+= nota;
i++;
}
devuelve suma/i; //La división que saque decimales!!
}
funcion saca_notas(lista de alumnos)
{
handler_db=conecta_con_base_datos(parámetros);
devuelve peticion_base_datos(handler_db,”todas las tuplas de la tabla patatin donde tupla.nombre_alumno este en la lista;”); //Una especie de join entre la lista de alumnos y la tabla patatin
}
Con la particularidad de que cada función se ejecuta en una máquina diferente, en este caso secuencialmente.
XML-RPC lo que hace es transferir las llamadas a los procedimientos y los resultados de éstos vía XML y HTTP. Hace peticiones en XML como ésta:
<methodCall>
<methodName>nombreProcedimiento</methodName>
<params>
<param><value><int>5</int></value></param>
<param><value><double>2.717218</double></value></param>
<param><value><string>cadena</string></value></param>
</params>
</methodCall>
Y la envía usando HTTP al servidor donde se encuentra la función, que usando igualmente HTTP y XML le da la respuesta.
No cuenta con la misma potencia que SOAP, que también funciona mediante XML, ni con la potencia ni complejidad de CORBA (usado en Gnome, ¿os suena Orbit? ¿Bonobo?), ni es el DCOM del .Net de Microsoft sólo para sistemas Microsoft.
Para evitar el lag en la comunicación con el servidor se le puede enviar una lista de procedimientos a ejecutar, en vez de enviar uno a uno esperando a cada respuesta.
Todo esto junto con ejemplos en mogollón de lenguajes de programación (C, C++, perl, python, ruby, java y algún otro) lo podéis encontrar en el breve howto de 26 páginas. Sorprende la facilidad con la que se programa en python o en ruby (¿ese do |a,b| en el código del servidor es una función anónima?) frente a la complejidad del código en C o en C++ donde hay que andar iniciando las librerías y demás. Se le rápido
Veamos un ejemplo en Python:
import xmlrpclib
# Create an object to represent our server.
server_url = ‘http://xmlrpc-c.sourceforge.net/api/sample.php’;
server = xmlrpclib.Server(server_url);
# Hacer la llamada al procedimiento.
result = server.nombreProcedimiento(5, 2.717218, “cadena”)
print “Resultado:”, result
hermoso y simple, ¿verdad?
He hechado en falta ejemplos en Lisp, porque desde luego Lisp tiene un interfaz para XML-RPC.
Next entries »
