Bien... supongo que quien tenga una PSP y tenga espíritu aventurero (o firmware 1.50) habrá pensado alguna vez hacerse un programita para la PSP... ver su "creación" en semejante aparatejo. Si tenéis una importante empresa y mucho dinero tal vez podáis pedir el SDK oficial a Sony y si a ellos les apetece, poder formar parte de los elegidos capaces de crear pequeñas joyas portables para disfrute de todos (o unos pocos). Por el contrario, si lo único que queréis es sacar el máximo partido posible a algo vuestro, usándolo como más os guste y sin tener que gastaros otra fortuna gracias al software libre (que, además, es gratuito), necesitaremos un SDK... no tan oficial como el de Sony pero que nos permitirá realizar nuestras propias aplicaciones. Eso vamos a intentar, configurar e instalar nuestro propio SDK (o homebrew como se conoce coloquialmente a este tipo de SDK's no oficiales).
Estado del arte
Bien, a partir de ahora llamaremos scene al estado del arte del homebrew, no por hacernos los "guays" sino porque en google obtendréis mejores resultados con "psp scene" que con "psp estado del arte". O dicho de otro modo: así se le llama a este mundillo.
Actualmente disponemos de un completo toolchain para las psp. Esto nos permitirá usar la potencia del gcc para crear ejecutables para nuestras consolas.
Además de programar en C, se han creado intérpretes de LUA y de python por lo que podremos empezar a crear programillas sin tener que meternos de lleno con el gcc. Además se han portado muchas librerías a LUA como por ejemplo SDL, etc. El python también está cada vez menos "verde", etc. De todas formas, aquí explicaremos como instalarnos el pspsdk homebrew, con lo que obtendremos el gcc-psp y los intérpretes de LUA y python así como muchas librerías interesantes tipo SDL. Vamos al trabajo!
Instalación del toolchain
Esto es lo primero y lo principal... sin esto no podemos empezar a hacer nada, nos bajaremos el repositorio de todo el SDK completo que, entre otras cosas, incluye estos scripts (yo uso el normal... no el "sudo"... bastantes emociones tengo ya... ;-)). Antes de instalarlo debemos asegurarnos que tenemos instalados los siguientes paquetes:
automake1.9
bison
dot2tex
doxygen
flex
libncurses5-dev
libreadline5-dev
texinfo
libusb-dev
libgmp3-dev
libmpfr-dev
libreadline-dev
Ahora descargamos el repositorio completo:
$svn co svn://svn.ps2dev.org/psp/trunk
Para ejecutar el script tendremos que establecer algunas variables en el sistema:
Es recomendable dejar fijos estos cambios, para ello (y si no queremos interferir en el resto de usuarios) modificaremos el archivo ~/.bashrc y añadiremos las siguientes líneas:
Ya sólo nos queda ejecutar el script del toolchain:
$cd trunk/psptoolchain
$./toolchain.sh
Bien, esto se descargará todas las herramientas de GNU necesarias, los últimos parches disponibles para ellas, los aplicará, compilará las herramientas y finalmente, las instalará. No hace falta ser root (no debemos serlo) ya que instala todo eso en /usr/local/pspdev y ahí podremos escribir si pertenecemos al grupo staff.
Instalación del homebrew
Tenemos la gran mayoría del homebrew recopilado en el repositorio subversion que descargamos anteriormente, además de unas cuantas librerías y utilidades bastante "entretenidas" (por ejemplo: SDL, prx-tools, etc.).. , sólo debemos compilarlo e instalarlo. No es difícil, es más bien repetitivo.
Ya que tenemos el compilador para psp listo, lo siguiente es compilar el pspsdk, que son las bibliotecas de acceso a los recursos de la psp:
Al igual que antes, no es necesario ser root en ninguno de los pasos, todo se instalará en los directorios de /usr/local/pspdev.
Instalación automática de librerías
Gracias a uno de los sceners que más han contribuído al pspsdk, un tal oopo, tenemos un script que nos descargan y compilan el resto de librerías extra como son zlib, SDL, etc. Para usar este script es necesario tener instalado libtool:
$cd trunk/psplibraries
$./libraries.sh
Esto nos instalará (en este orden): zlib, bzip2, freetype, jpeg, libbulletml, libmad, libmikmod, libogg, libpng, libpspvram, libTremor, libvorbis, lua, pspgl, pspirkeyb, sqlite, SDL, SDL-gfx, SDL-image, SDL-mixer, SDL-ttf, smpeg-psp y zziplib. ¿Suficiente? ;-)
Instalación manual de librerías
Si no queremos instalar todo eso, podemos instalar las que deseemos una a una, a modo de ejemplo vamos a instalar una libreria, aunque el sdk incluye muchas, todas se suelen hacer de igual o similar forma. En cualquier caso, en cada directorio tenéis un fichero README.PSP que os lo explica, así como si la librería tiene dependencias (en cuyo caso hay que compilar e instalar sus dependencias antes). Vamos a instalar SDL, por ejemplo: leemos su archivo README.PSP y encontramos las instrucciones para hacerlo:
Repito que en ningún paso es necesario ser root. Esto instalará las librerías para psp y sus cabeceras. En el README.PSP explican cómo escribir aplicaciones para psp que usen estas librerías, incluyendo las opciones del compilador.
El orden de instalación de las utilidades y las librerías que YO he seguido es el siguiente:
psptoolchain
pspsdk
cppunit
pspgl
SDL
SDL_gfx
jpeg
zlib
libpng
SDL_image
libTremor
libogg
libvorbis
libmikmod (ver parche más abajo)
mikmodlib
cpplibs
SDL_mixer
freetype
SDL_ttf
cal3D
Con esto tendréis toda la versatilidad de SDL al alcance de vuestra psp ;-) (así como otro montón de librerías interesantes).
Nota: libmikmod compila y se instala sin problemas, sin embargo, no se puede usar de forma "automática" en tus compilaciones porque no se ha incluído el programa libmikmod-config. Yo he creado el mio propio que debéis copiar en /usr/local/pspdev/psp/bin (bueno... depende de donde estéis instalando todo, en realidad sería en $(psp-config -p)/bin). Una vez compilado e instalado libmikmod copiáis este archivo y seguís la instalación de las librerías de forma normal.
#! /bin/sh
prefix=`psp-config -P`
exec_prefix=${prefix}
exec_prefix_set=no
usage="Usage: libmikmod-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] \
[--libs] [--cflags] [--ldadd]"
if test $# -eq 0 ; then
echo "${usage}" 1>&2
exit 1
fi
while test $# -gt 0 ; do
case "$1" in
-*=*) optarg=`echo "$1" | sed 's/[-_a-zA-Z0-9]*=//'` ;;
*) optarg= ;;
esac
case $1 in
--prefix=*)
prefix=$optarg
if test $exec_prefix_set = no ; then
exec_prefix=$optarg
fi
;;
--prefix)
echo $prefix
;;
--exec-prefix=*)
exec_prefix=$optarg
exec_prefix_set=yes
;;
--exec-prefix)
echo $exec_prefix
;;
--version)
echo 3.1.11
;;
--cflags)
includedir=${prefix}/include
if test $includedir != /usr/include ; then
includes=-I$includedir
fi
echo $includes
;;
--ldadd)
;;
--libs)
libdir=-L${exec_prefix}/lib
echo $libdir -lmikmod -L`psp-config -P`/lib -L`psp-config \
-p`/lib -lm -lpspvfpu -lpspdebug -lpspgu -lpspctrl -lpspge -lpspdisplay \
-lpsphprm -lpspsdk -lpsprtc -lpspaudio -lc -lpspuser -lpsputility -lpspkernel
;;
*)
echo "${usage}" 1>&2
exit 1
;;
esac
shift
done
DevKit Pro
Gracias a la inestimable ayuda de Paco, disponemos de un paquete debian con la toolchain y el pspsdk completo, como podéis ver en este aviso. Funciona perfectamente, pero no se puede compilar e instalar directamente el resto de librerías puesto que los scripts del homebrew son un poco cutres y hay que maquillarlos un poquito... cuando tenga tiempo intentaré buscar alguna solución...
Conclusiones
Bueno... con esto tendréis un completo entorno de desarrollo para psp. Era el objetivo de la receta. De todas formas falta aún una cosa: crear un archivo EBOOT.PBP listo para su ejecución en la consola. El problema se reduce a tener el Makefile apropiado. Os sugiero que os descarguéis el código fuente del port del maravilloso ScummVM, tiene el mejor Makefile sobre el tema que he visto. De todas formas, si no dáis con ello, se hace una receta y en paz, ok?
Disfruten! :-)
Cómo compilar e instalar los drivers para las tarjetas WiFi RT2500 de Ralink en GNU/linux
Introducción
Las tarjetas wifi con chipset Ralink RT2500 cada vez son más comunes. Se encuentran integradas en muchos equipos portátiles y como tarjetas PCMCIA para portátiles, por ejemplo. Por desgracia, los núcleos Linux no traen soporte para este chipset. Poe eso hay tienes que añadirlo tú, aunque la tarea es bastante más fácil de lo que puede parecer.
Lo primero, ¿Tienes una RT2500?
Bueno, para los menos versados en este tema, la forma de saber qué chipset utiliza tu interfaz wireless (así como cualquier hardware de nuestro equipo) es con el comando lspci.
Cuando ejecutes este comando, podrás ver una lista de todos los dispositivos PCI que tienes en tu sistema (si tienes insertada alguna PCMCIA en tu también aparecerá). Ahora solo queda buscar el dispositivo de red que tengas instalado y si ves que su chipset es RT2500 puedes continuar.
Qué necesitamos
Necesitas los fuentes del driver. Éstos se pueden obtener de varias maneras:
Paquete debian:
$apt-get -f install rt2500-source
Bajarte el Código Fuente del driver directamente de internet. De esta forma podrás conseguir la última versión disponible.
También necesitas los headers del núcleo que estés utilizando. En Debian:
# apt-get -f install linux-headers-$(uname -r)
Ahora ya puedes continuar con la compilación.
Compilación e instalación
En primer lugar deberemos crear un enlace hacia el directorio en el que están nuestros headers que se llame linux para que a la hora de compilar se encuentren todas las librerias necesarias:
$ cd /usr/src/
$ ln -s kernel-headers-2.6.8-1-686 linux
Otra cosa importante es que debes compilar este driver con la versión 3.4 de gcc, si no, es muy probable que surjan problemas. Si no lo tienes instalado:
# apt-get -f install gcc-3.4
Ahora ya estás en condiciones de descomprimir los fuentes y compilarlos. Si has descargado los fuentes con apt, éstos se encontrarán en /usr/src/rt2500.tar.gz. Descomprímelos y compílamos:
$ tar -zxvf rt2500.tar.gz
$ cd modules
$ make CC=gcc-3.4
Una vez compilado todo sin problemas, puedes proceder con la instalación:
$ make install
La instalación habrá creado el fichero /etc/modprobe.conf. Dentro de este fichero habrá algo del estilo 'alias ra0 rt2500'. Tienes que copiar esa línea dentro del archivo /etc/modules.conf y después borrar el archivo /etc/modprobe.conf.
Con esto, se supone que el driver ha quedado instalado. Ahora tan solo queda cargar el módulo:
# modprobe rt2500
Si esto no funciona (que debería), puedes probar esto otro (dentro del directorio donde has compilado el driver):
# insmod rt2500.ko
y con esto el driver deberia quedar perfectamente instalado y tu dispositivo de red detectarse como ra0.
A veces (sobre todo con las versiones más nuevas de Linux) el comando depmod parece no funcionar bien, por ello, es conveniente, después de tener el módulo cargado ejecutar:
# update-modules
Con ello habrás actualizado correctamente la lista de módulos y el correspondiente a tu WiFi se cargará durante el arranque.
Aunque realmente el copyleft tenga, en teoría, poco o nada que ver con el software libre, bien es verdad que defiende la cultura libre de la que tantas veces ehmos hablado aquí, en la lista, y por suerte con David Bravo cuando nos visitó hace un par de meses en la ESI ... pero vean y disfrutend e este artículo que encontré en Banddaancha.st. El títular, sin desperdicio:
En primer lugar quiero decir que todos los administradores y editores agradecemos que cada vez más gente empiece a escribir recetas, que son la columna vertebral de este portal.
Supongo que todos lo habéis visto en Barrapunto, pero lo pongo de todos modos para que quede constancia. Está bien que se vea que en Castilla La-Mancha hay gente que de verdad usa y contribuye al software libre, y no sólo dice que lo usa. Mi enhorabuena desde aquí para Carlos González Morcillo, profesional donde los haya, y también para su equipo. Si todos los profesores hicisemos nuestro trabajo la mitad de bien que Carlos, seríamos la mejor universidad de España, como poco.
A menudo se piensa que una aplicación estaría mucho mejor si se encontrara en varios idiomas. Podemos pensar en distintas formas de soportar esto, pero otros ya lo han pensado por nosotros y han creado las fabulosas herramientas gettext. Este documento pretende ser una guía para el uso rápido (rápido de verdad) de estas herramientas.
Ingredientes
gettext
Modificaciones en el código
Lo primero es acordarse de evitar cadenas sin más (al menos las que se muestran) en nuestro código. Ahora importaremos la librería gettext y utilizaremos la función gettext. Se encuentra disponible para numerosos lenguajes, aunque aquí se explicará con ejemplos en python (las diferencias serán mínimas en el resto de lenguajes).
No os asustéis: Las funciones “textdomain” y “bindtextdomain” sirven para decirle a gettext dónde se encuentran las traducciones. Aquí se está poniendo un ejemplo, así que sustituid “programita” por el nombre de vuestro programa, y “./mo” por el directorio donde vamos a meter las traducciones.
A menudo, además, se suele importar la función gettext cambiándole el nombre a algo más sencillo como la barra baja. De esta manera, nos evitamos tener que escribir “gettext.gettext” cada vez. Para hacer esto hay distintas maneras, una de ellas es durante la importación:
fromgettextimportgettextas_
Generación de la plantilla de traducción (.pot)
Podemos obtener la plantilla del código en casi cualquier lenguaje: C, C++, Python, Perl, Glade, Java, … Y se hace así:
$xgettext --language=Python -j programita.py
Las opciones son: —language indicando el lenguaje del código, y -j que indica que, si hay ya un .pot existente, se deben mezclar los mensajes.
Si hemos usado algún cambio y no aparece la función como “gettext”, será necesario usar también la opción —keyword. Por ejemplo:
$xgettext --language=Python -j-k _ programita.py
Ale, ya tenemos el messages.pot.
Generar el fichero de traducciones (*.po)
Ahora se utiliza el messages.pot para generar cada plantilla. Nosotros queremos la traducción al castellano, así que será es.po:
$msginit -i messages.pot -o es.po
Ahora viene la parte en la que editamos el fichero es.po (yo suelo usar gtranslator o kbabel) y demás.
Mezclar el fichero de traducciones (.po) con una nueva plantilla (.pot)
Este sistema sería poco eficiente si tuviéramos que traducirlo todo de nuevo cada vez que se cambie el fuente. Por ello, hay un sistema por el que se mezcla el fichero ya traducido con la plantilla nueva (es decir: volvemos al paso de creación de plantilla y después ejecutamos esto):
$msgmerge -U es.po messages.pot
Y, nuevamente, volvemos a traducir :-D
Creación del fichero de equivalencias (.mo)
Realmente, el ficherito .po no se utiliza en el ejecutable. Es necesario utilizar un ficherito .mo. Aquí crearemos nuestro es.mo, como es lógico:
$msgfmt es.po mo/es/LC_MESSAGES/programita.mo
Como podéis observar, el resultado lo dejamos en mo/es/LC_MESSAGES/. Eso lo hacemos así porque en el código fuente dijimos que las traducciones colgarían del directorio mo, el idioma es Español (las locales son “es”), y porque todos los .mo deben colgar de un directorio LC_MESSAGES dentro de las locales para que sea encontrado correctamente.
Utilización
Ya está. No hay nada más que contar. Si las locales son “es”, escribirá nuestra traducción, y si son “en”, lo escribirá en inglés. Eso es todo.
Ejemplo
Veamos un ejemplo, sugerencia hecha por david.villa:
Editamos el archivo es.po que se nos habrá creado, traduciendo la única cadena. Mi archivo pinta así:
# Spanish translations for PACKAGE package.
# Copyright (C) 2010 THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# miguel <miguelangel.garcia@gmail.com>, 2010.
#
msgid""msgstr"""Project-Id-Version:PACKAGEVERSION\n""Report-Msgid-Bugs-To:\n""POT-Creation-Date:2010-05-2507:31+0200\n""PO-Revision-Date:2010-05-2507:32+0200\n""Last-Translator:miguel<miguelangel.garcia@gmail.com>\n""Language-Team:Spanish<>\n""MIME-Version:1.0\n""Content-Type:text/plain; charset=ASCII\n"
"Content-Transfer-Encoding:8bit\n""Plural-Forms:nplurals=2; plural=(n != 1);\n"
#: hello.py:12
msgid "hello, world!"msgstr"hola,mundo!"
Por ahora no nos fijaremos mucho en las cosa que deberíamos cambiar, como el PACKAGE y demás. Sólo nos queda compilar:
