il libero

El 9 de junio se va a realizar la 2da Jornada Python en el Auditorio de la UTN – Facultad Regional Santa Fe, organizado por el LUGli. Las charlas se realizarán desde las 8.30 hasta las 18.30. Las mismas cubren una gran variedad de niveles, desde básicas como “Introducción a Python“, a muy avanzadas como “Usando Python para testeos de seguridad mediante simulación automática de ataques“. La entrada es libre y gratuita.

Python es un lenguaje de programación libre, multiplataforma, poderoso y al mismo tiempo muy fácil de utilizar. Si bien, siendoles sincero, nunca lo he aprendido y utilizado (por falta de tiempo), sí he visto código y experiencias de profesionales que afirman esto. Si estas interesando en aprender un nuevo lenguaje de programación, te recomiendo elegir python, y asistir a estas jornadas, que se realizan por segundo año consecutivo en nuestra ciudad. Es muy recomendable registrarse, y de ser posible, adquirir un certificado del evento, no sólo por las razones obvias, sino también para apoyarnos económicamente.

Si tu proyecto en Java tiene una clase que no pertenece a ningún paquete (no posee al principio la sentencia “package…”), entonces pertenece al default package. Si intentan utilizar esa clase desde otra clase sin paquete no hay problemas, pero es imposible hacerlo (a partir de java 1.4) desde clases que sí pertenecen a algún paquete. Averiguar esto me llevó gran parte de la tarde. Ya veo que le pifié en algo y la cosa era mucho mas sencilla…

Bueno, ese es el problema con la clase Calculador que proveyó la cátedra de Inteligencia Artificial. No tiene paquete. Si ya se armaron todo su código ordenadito en paquetes no van a poder utilizarla. Sólo se puede desde una clase sin paquete… pero queda muy desordenado poner todas las clases en un mismo paquete, y además no es recomendado.

Pero hay una solución. Podemos seguir teniendo nuestro proyecto ordenado y utilizar esta bendita clase.

(more…)

… o “Diciendo estupideces sobre orientación a objetos”. Sigan leyendo el post y después se darán cuenta de cuál es el título que tiene que ir.

La semana que viene entregamos el TP final de DIED. Se trata de una especie de calculadora avanzada. Comenzó como un evaluador de expresiones. Luego se extendió para soportar funciones de usuario personalizadas, como “sumar(a,b) = a + b”, y finalmente el software tiene que graficar funciones, y también aproximar con la técnica de diferencias divididas (disculpen el habérselo recordado). Con respecto a esto último, uno va agregando puntos en un eje cartesiano, los mueve, lo borra, y el polinomio se va generando/graficando en vivo y en directo.

(more…)

Quiero compartir con ustedes unas herramientas muy simples que usamos para hacer los trabajos prácticos de DISO.

Son, como dije, muy sencillas: dos sirven para ayudar a armar la documentación (LaTeX), y la otra es para chequear si los archivos que tenemos en nuestra máquina son iguales a los que están en Minix (es decir, con los que estuvimos probando realmente).

Seguramente este post no es de mucho interés para todos, pero quizá les sirva si alguna vez realizan un TP con LaTeX, en el cual deban incluir código fuente de algún programa, o publicar sólo las modificaciones de algún archivo existente (diff).

(more…)

De eso se trató el TP2 de DISO (Diseño e implementación de Sistemas Operativos). Al terminar de implementar una idea de cómo hacerlo, debíamos correr un programa dos veces, cambiarle la prioridad a uno de los dos, y verificar que uno imprimía más veces su pid que el otro.

El enunciado era claro, y guiaba bastante en cómo hacerlo. Además ya habíamos asistido a una clase de práctica, por lo que no deberían haber aparecido complicaciones mayores. Aunque en realidad no terminó siendo así.

Estaría muy bueno saber cómo hace la gente del kernel Linux para debuggearlo. Pablo Pessolani, el profesor de teoría y titular de DISO, nos explicaba que la técnica consiste en usar la muy conocida función printf, así de simple. Luego de reflexionarlo un poco, la verdad es que no parece haber otra alternativa. Siguiendo la misma estrategia, así fue como testeamos el código modificado de Minix 2.0.2 para completar el trabajo práctico 2.

Sin embargo me quedó la pica de cómo hacen los hackers de Linux para testear sus modificaciones. Pensaba que quizá tengan alguna forma más cómoda y adecuada. Entonces averigué qué técnicas utilizan, por simple curiosidad, y me sorprendió un poco el descubrimiento.

(more…)

En Diseño e implementación de Sistemas Operativos (diso, de a aquí en mas) tenemos que tocar el código fuente del kernel Minix. El primer trabajo práctico se trata de la implementación de una llamada al sistema.

Por supuesto que utilizamos algún emulador para correr este mini Unix. Pero ¿cómo trabajar? ¿cómo modificar el kernel y testearlo? ¿Desde Minix con vi y la shell que no recuerda los comandos que ejecutamos?. Estaría bueno trabajar en GNU/Linux (o el sistema que utilicemos), mover los cambios de alguna forma a la partición de Minix, compilar allí y verificar que todo funcione correctamente.

(more…)