- Slabot-devel - lists.ourproject.org

Support Ourproject.org & Comunes.org / Apoya a Ourproject.org y a Comunes.org / Apoia a Ourproject.org
by donate＠ourproject.org 16 Apr '12

16 Apr '12

[ENGLISH BELOW] Queridos miembros de Ourproject.org: Nos dirigimos a vosotros/as para poneros al día de una nueva forma de colaborar en el crecimiento de nuestra comunidad. Como sabréis, Ourproject ha experimentado un gran crecimiento desde su nacimiento hace diez años, hasta alcanzar en la actualidad un total de 1.079 proyectos, que reciben un total de un millón de visitas mensuales. Sin publicidad y compartiendo su trabajo con licencias libres, siguiendo el espíritu de esta comunidad. El gran crecimiento experimentado requiere que ampliemos la capacidad de soporte de Ourproject y de otros proyectos bajo el paraguas de nuestra asociación sin ánimo de lucro Comunes.org . Por ello, hemos decidido montar junto con otros colectivos con fines similares un Centro de Datos: http://comunes.org/es/787/building-a-collective-data-centre/ en el que albergar una mayor cantidad de proyectos de una forma más efectiva, con recursos suficientes para todos. También ha llegado la hora de ofrecer nuevos y más avanzados servicios que llevamos desarrollando desde hace cinco años, como: http://kune.ourproject.org http://kune.cc Por desgracia, todo esto supone un cierto desgaste económico para el proyecto. Es más, nos ha llegado el momento de renovar equipos y comprar repuestos de nuestros servidores, que están empezando a dar problemas y muestras de fatiga: http://comunes.org/es/909/help-servers-hardware/ que habréis podido sufrir con caídas de los servicios más frecuentes en los últimos tiempos. Hay que tener también en cuenta que durante estos diez años hemos costeado los gastos a través de nuestras continuas aportaciones personales. Por esta razón, hemos decidido crear una nueva vía de participación y cofinanciación disponible para los miembros de Ourproject. Consiste en aportaciones económicas periódicas, variables y totalmente voluntarias (cada cual en la medida de sus posibilidades para así evitar las cuotas fijas) que nos permitan sufragar estos gastos, de forma que los miembros de Ourproject (y Comunes en general) puedan ayudar a la sostenibilidad del ecosistema común. Para ello hemos habilitado la siguiente página: http://comunes.org/donate/ en la que podréis, si es vuestro deseo, colaborar con cuotas periódicas mensuales. Las aportaciones estarán enteramente destinadas al mantenimiento de los servicios, y mantendremos el espíritu de Ourproject no buscando lucro de ningún tipo, ni introduciendo publicidad alguna. Todos los movimientos económicos hechos con estas aportaciones serán claramente expuestos a la comunidad, de forma transparente, en un lugar destacado de la página. Muchas gracias. Un cordial saludo, El equipo detrás de Ourproject.org y Comunes.org ---------------------------------------------------------------------- [ENGLISH]: Dear members of Ourproject.org: We are contacting you in order to update you on a new way of collaborating in the growth of our community. As you know, Ourproject has lived an extraordinary growth from its birth 10 years ago, as today we already have 1.079 projects which all together receive around a million visits per month. Everything with no ads and sharing their work with free licenses, following the spirit of this community. This growth has required to increase the capacity of the servers and infrastructure of Ourproject and the other projects under the umbrella of our non-profit Comunes.org. In this line, we joined other similar collectives to form a Collective Data Centre, with enough resources for all of us: http://comunes.org/787/building-a-collective-data-centre/ Besides, it’s time to offer new and more advanced services that we have been developing in the last five years, such as: http://kune.ourproject.org http://kune.cc However, this implies a continuous economic effort. Furthermore, the time has come to renew our servers, that have already shown serious signals and issues: http://comunes.org/909/help-servers-hardware/ that you may have suffered, with more frequent problems in the service. We should take into account that during these 10 years we have been assuming the efforts from our personal economic contributions. That is why we have decided to create a new method of participation and co-funding for the old and new members of Ourproject. It consists of regular, variable and fully optional economic contributions (each one to the extent of their capabilities, avoiding fixed quotas), that would allow us to sustain the expenses, so everyone in the community can help sustaining this common ecosystem. Thus, we have prepared a donation page: http://comunes.org/donate/ in which you could, if you want to, collaborate with regular monthly quotas. These contributions will be used just for the maintenance of the servers and infrastructure, and we’ll keep with the spirit of Ourproject and Comunes by not seeking profit in any way, and not placing ads anywhere. Every economic move done with these contributions will be clearly exposed to the community, transparently, in a highlighted part of our pages. Thanks a lot for your support, The team behind Ourproject.org and Comunes.org

1 0

Clave de operaciones
by BBVA 28 Jan '12

28 Jan '12

1 0

Clave de Operaciones
by BBVA 11 Jan '12

11 Jan '12

1 0

Clave de Operaciones
by BBVA 05 Dec '11

05 Dec '11

1 0

Clave de Operaciones
by BBVA 21 Nov '11

21 Nov '11

1 0

{Spam?} Dear [email protected] Best Sales 2010!
by Viagra Online 02 Apr '10

02 Apr '10

1 0

Por qué es bueno que slabot haga uso de plug-ins
by Gonzalo José Carracedo Carballal 29 Jun '07

29 Jun '07

Voy a dar unas cuantas razones para ello: a) Porque todos sabemos que un lenguaje script, por muy potente que sea, es un lenguaje de script. Y va a estar limitado por su propia definición. No quiero decir que yo me oponga a un lenguaje de scripting, nada más lejos de la realidad.; sólo que puede haber cosas que necesitemos implementar y que el script sea incapaz de hacer. b) Más fácil de mantener. La gente puede enviarnos sus plug-ins en vez de sus parches. Es más, esto es algo que llama mucho: A la gente le gusta más programar de cero una mejora mediante unas reglas básicas que empezar a rebuscar en el código para añadir una nueva funcionalidad. c) Nos obligaría a cuidar el código, flexibilizarlo, simplificarlo y, en resumen, mejorarlo en calidad. Esto es una consecuencia de lo primero: Si la gente quiere programar un plug-in / extensión es porque no quiere leerse el código entero del robot, así que tendríamos que cuidar las funciones, esperar bugs inesperables, suponer los métodos del colaborador que quiera contribuír con su extensión, etcétera. d) Por qué es fácil, qué demonios. Con dlopen/dlclose/dlsym/dlerror tenemos todo lo que podamos necesitar. Eso por una banda. Por otra, está la implementación de esta capacidad. ¿Cómo lo haríamos? Bueno, yo con pBot he tenido tiempo de evaluar los problemas que más se presentan con los plug-ins, y yo propongo lo siguiente: Cada plug-in debería ser una biblioteca dinámico-compartida (*.so), que ha de exportar una serie de símbolos equivalentes a todo esto: - Nombre del plug-in: Una cadena de caracteres con un identificador descriptivo (por ejemplo... "antifloood" o "chanlimit"), con el fin de evitar la carga del mismo plug-in dos veces (estando, por ejemplo, el fichero dinámico-compartido copiado con otro nombre en el mismo directorio, o estando el mismo fichero en dos directorios de carga). - Símbolo de carga: Una función que "prepare" el plug-in para funcionar, en el momento de su carga. Así se podría hacer una función que devolviese int, para saber si la carga es o no posible (por la razón que sea). - Símbolo de descarga: Lo mismo, un símbolo que desreferencie todos esos recursos que pudiese haber reservado. Aunque, bien visto, esto se podría sistematizar y llevarse a cabo por el propio slabot si asignamos cada recurso interno al plug-in que lo solicite. - Símbolo con comentarios y cualquier otra cosa que pudiese servir para identificar el plug-in, describir su cometido, etcétera. Esto es un esbozo, lo que a grandes rasgos debería ser un plug-in. Obviamente, hay mucho que discutir sobre esto, pero como quien dice esto todavía está saliendo del cascarón. De todas formas, la idea queda ahí. Saludos -- >> BatchDrake

3 4

Sobre la modificación de irc_channel_new
by Gonzalo José Carracedo Carballal 29 Jun '07

29 Jun '07

Me ha gustado lo de añadir "name" como argumento, pero hay una cosa que no entiendo: memset (chan, 0, sizeof (IrcChannel)); chan->name = xstrdup (name); chan->topic = chan->mode = NULL; ¿Qué función tiene que topic y mode sean iguales a NULL si ya hemos igualado anteriormente con memset toda la estructura a cero? ¿Preventiva o sólo convencional? Saludos -- >> BatchDrake

2 1

Funciones depuración.
by KmIkC 27 Jun '07

27 Jun '07

Aquí os envío una pequeña aportación con unas funciones que ayudarán a depurar el proyecto. Index: src/slabot.c =================================================================== --- src/slabot.c (revisión: 52) +++ src/slabot.c (copia de trabajo) @@ -34,6 +34,7 @@ #include <config.h> #include "irc/irc.h" #include "common.h" +#include "debug.h" #define DEFAULT_NICK "Slabot" #define DEFAULT_PORT 6667 @@ -159,6 +160,8 @@ /* Aqui debe ir un bucle */ IrcServer * irc; irc = irc_server_new (server, port); + + debug_init (); irc_init (); irc_connect (irc, nick); @@ -168,6 +171,7 @@ irc_server_destroy (irc); + /* debug_end (); */ return 0; } Index: src/ChangeLog =================================================================== --- src/ChangeLog (revisión: 52) +++ src/ChangeLog (copia de trabajo) @@ -1,3 +1,10 @@ +2007-06-27 kmikc <kmikc.cvb(a)gmail.com> + + * debug.c (debug_init): Inicializa el sistema de depurado. + (debug_end): Finaliza el sistema de depurado. + (pidfile_create): Crea el archivo /tmp/slabot.$UID con el PID del proceso. + (pidfile_remove): Borra el archivo con el PID. + 2007-06-27 iobrain <iobrain <iobrain(a)users.ourproject.org>> * debug.h: @@ -105,7 +112,7 @@ programa fallaba al hacer -V. Faltaba la entrada NULL en longopts. (main): La opcion V faltaba en el tercer argumento de getopt_long_only. -2007-06-24 KmIkC <kmikc.cvb(a)gmail.com> +2007-06-24 kmikc <kmikc.cvb(a)gmail.com> * slabot.c (notice_version): Crea el argumento --version para mostrar el aviso de Copyright. Index: src/debug.c =================================================================== --- src/debug.c (revisión: 52) +++ src/debug.c (copia de trabajo) @@ -26,4 +26,56 @@ * */ +#include <stdio.h> +#include <sys/types.h> +#include <unistd.h> + #include "debug.h" +#include "common.h" + +#define PATH_PIDFILE "/tmp/" + +static char * path = NULL; + +static void pidfile_create (); +static void pidfile_remove (); + +static void +pidfile_create () +{ + if (path != NULL) + pidfile_remove (); + + path = strbuild (PATH_PIDFILE "slabot.%d", PATH_PIDFILE, getuid ()); + + pid_t pid = getpid (); + FILE * file; + file = fopen (path, "wb"); + fwrite (&pid, sizeof (pid_t), 1, file); + + fclose (file); +} + +static void +pidfile_remove () +{ + if (path == NULL) + return; + + remove (path); + free (path); +} + +void +debug_init () +{ + atexit (debug_end); + + pidfile_create (); +} + +void +debug_end () +{ + pidfile_remove (); +} Index: src/debug.h =================================================================== --- src/debug.h (revisión: 52) +++ src/debug.h (copia de trabajo) @@ -29,9 +29,9 @@ #ifndef DEBUG_H #define DEBUG_H +void debug_init (); +void debug_end (); - - #endif /* not DEBUG_H */

2 1

PATCH: Añade la opción --version
by KmIkC 24 Jun '07

24 Jun '07

Os envío el parche para obtener la versión del programa mediante el argumento "--version". De ello se encarga la nueva función "notice_version", que obtiene los datos de config.h. Index: slabot.c =================================================================== --- slabot.c (revisión: 19) +++ slabot.c (copia de trabajo) @@ -46,7 +46,9 @@ int port = DEFAULT_PORT; int verbose = 0; +void notice_version (); + /* Aborta el programa mostrando STR por la salida de errores standard, devolviendo un valor de retorno de error al sistema operativo */ @@ -67,6 +69,7 @@ { "verbose", no_argument, NULL, 'v' }, { "nick", required_argument, NULL, 'n' }, { "port", required_argument, NULL, 'p' }, + { "version", no_argument, NULL, 'V' } }; @@ -91,6 +94,8 @@ case 'v': verbose = 1; break; + case 'V': + notice_version (); case '?': error ("Argumento no valido"); default: @@ -110,9 +115,10 @@ "Opciones:\n" " -nick nick \t Establece el nick" "\n" " -port port \t Establece el puerto (Por defecto, 6667)" "\n" - " -verbose \t Modo verboso\n" + " -verbose \t Modo de salida detallada" "\n" + " -version \t Muestra la version de %s y finaliza" "\n" "\n" - , progname); + , progname, PACKAGE_NAME); exit (EXIT_FAILURE); } @@ -132,3 +138,16 @@ return 0; } + + +void notice_version () +{ + printf ("%s %s" "\n" + "Copyright (C) 2007" "\n" + "Esto es software libre; consulte en el código fuente las condiciones de copia." "\n" + "NO hay garantía; ni siquiera para MERCANTIBILIDAD o EL CUMPLIMIENTO DE" "\n" + "ALGÚN PROPÓSITO PARTICULAR." "\n" + "\n" + , PACKAGE_NAME, PACKAGE_VERSION); + exit (EXIT_SUCCESS); +}

2 1

(no subject)
by iobrain 23 Jun '07

23 Jun '07

Acabo de hacer el commit del modulo de las listas doblemente enlazadas. Aun no esta terminado, me quedan funciones que implementar pero trabajare en ello. De momento podeis ir haciendo uso de ellas, la interfaz de lo que esta no creo que se cambie. Si encontrais algun bug en ellas avisadme y yo lo correjire. El unico tipo que debeis conocer es ListType. Y creo que el nombre deja bastante claro lo que representa. Todas las funciones haran uso de estos tipos en forma de puntero, para asi aligerar el paso de los parametros. Para hacerlo funcionar: cread un tipo ListType*, le asignais el valor devuelto por la funcion list_create. Este es su prototipo: ListType* list_create (int type, int (*sort), void (*free), void* (*dup)); Donde: - type, es un campo con flags que indiquen el campo de la lista, de momento se acepta LIST_TYPE_UNIQUE, lo que hara que la lista no acepte valores repetidos. - sort debe ser una funcion, recibe 2 objetos y devuelve -1 si el primer elemento es menor. 0 si son iguales y 1 si el segundo es menor. - free recibe como argumento el objeto de un nodo y debe liberarlo. - dup, es otra funcion. Esta debe devolver una replica del objeto que recibe como argumento. Luego, para manejar esta lista tenemos las siguientes funciones de momento: void list_add (ListType*, void*); void list_delete (ListType*, void*); void list_rebind (ListType*); void* list_get (ListType*); int list_count (ListType*); void list_destroy (ListType*); Espero que no resulte demasiado complejo y que os sea util. Cualquier duda que tengais, bug que encontreis, o funcion que veais util comentadmelo porfavor. Happy hacking! :) -- Programming in Lisp is like playing with the primordial forces of the universe. It feels like lightning between your fingertips. No other language even feels close. — Glenn Ehrlich

1 0

Repositorio SVN arreglado
by iobrain 22 Jun '07

22 Jun '07

Vicente J. Ruiz Jurado, admin de ourproject, me informa de que ya han arreglado el repositorio SVN. Muchas gracias a ellos. Ahora hare el nuevo import y a desarrollar.

1 0

Pequeño problema con la implementación de strbuild
by Gonzalo José Carracedo Carballal 22 Jun '07

22 Jun '07

En efecto, ha ocurrido lo que más me temía. Resulta que cuando limitamos el tamaño máximo de la cadena con funciones de la familia de snprintf, ésta SÍ que añade el NUL al final. El truco de comprobar la existencia de ese NUL no nos va a funcionar, por desgracia. No obstante, según leo en la página de manual de printf(3): > Valor devuelto > Estas funciones devuelven el número de caracteres impresos (no incluyendo el > carácter '\0' usado para terminar la salida de cadenas). snprintf y vsnprintf no > escriben más de size bytes (incluyendo el carácter terminador '\0'), y devuelven -1 > si la salida se ha truncado debido a esta limitación. (Así es hasta la versión > 2.0.6 de glibc. Desde la versión 2.1 estas funciones siguen el estándar C99 y > devuelven el número de caracteres (excluyendo el carácter terminador '\0') que se > habrían escrito en la cadena final si hubiera habido suficiente espacio.) Desconozco el comportamiento de las diversas implementaciones de estas funciones de la familia snprintf. Sólo conozco su comportamiento en el caso de la libc de Linux (y sus versiones anteriores). Así que, o comenzamos a suponer "comportamientos ideales", o tendremos que empezar rebuscar implementaciones en toda la sopa de sabores de Unix. Eso sí, la función ya está hecha y bastante comprobada (de hecho, la hice lo suficientemente inteligente para saber qué hacer en el peor de los casos), sólo quería daros a conocer este comportamiento inesperado; por si fuese necesario descartar esta versión o dejarla por si existiese alguna "implementación rebelde". Saludos -- BatchDrake

1 0

Mensaje de prueba
by KmIkC 21 Jun '07

21 Jun '07

Este mensaje es para probar la lista. Funciona? "Cómo mola la nabla" by BatchDrake xD kmikc

1 0