You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(5) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Muammar El K. <mu...@pr...> - 2010-02-16 19:49:22
|
Hola, 2010/2/14 CaStarCo <cas...@gm...>: > Bien, no se cuanto tiempo más le podré dedicar a tabularium, pero ahora > tengo algo de tiempo libre (no sé si durará mucho) y dedicaré un poco de > éste al proyecto a ver qué tal avanza. Qué bueno. Eres el líder de ese desarrollo :) > Vuestros comentarios y contribuciones serán bienvenidos, haré una lista de > cosas por hacer por si alguien quiere aportar su granito de arena. Cuando tengas esa lista, no dudes en escribir. > Más cosas, parece ser que SourceForge ateniendose a la ley estadounidense > está bloqueando el acceso a su web a los ciudadanos de países pertenecientes > a la lista negra de su gobierno, estan en ellos los denominados países > pertenecientes al "eje del mal" y otros como Cuba. Como no estoy de acuerdo > con la medida ya que estamos hablando de software libre, pero SourceForge > sigue siendo una plataforma interesante por las ventajas que brinda, os > recuerdo que el código es accesible en gitorious.com para todas aquellas > personas residentes en países pertenecientes a dicha lista negra. > Excelente tu posición. Estoy de acuerdo en mantener el código accesible en gitorious. Pensaba que el software libre estaba exento de estos problemas políticos, pero ya se ve que no. > Saludos a todos! Saludos y estamos en contacto. -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- |
From: CaStarCo <cas...@gm...> - 2010-02-14 09:41:04
|
Bien, no se cuanto tiempo más le podré dedicar a tabularium, pero ahora tengo algo de tiempo libre (no sé si durará mucho) y dedicaré un poco de éste al proyecto a ver qué tal avanza. Vuestros comentarios y contribuciones serán bienvenidos, haré una lista de cosas por hacer por si alguien quiere aportar su granito de arena. Más cosas, parece ser que SourceForge ateniendose a la ley estadounidense está bloqueando el acceso a su web a los ciudadanos de países pertenecientes a la lista negra de su gobierno, estan en ellos los denominados países pertenecientes al "eje del mal" y otros como Cuba. Como no estoy de acuerdo con la medida ya que estamos hablando de software libre, pero SourceForge sigue siendo una plataforma interesante por las ventajas que brinda, os recuerdo que el código es accesible en gitorious.com para todas aquellas personas residentes en países pertenecientes a dicha lista negra. Saludos a todos! -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2010-01-01 14:44:40
|
Buenas Alejandro, como has visto estos días he parado algo el desarrollo porque me han cargado de trabajo en la universidad, en cuanto tenga tiempo libre asegurado os comento algo. ¿Cómo queréis hacer la reunión online? Nuestros horarios son algo (bastante) diferentes por estar yo en España :p, bueno, eso es algo que tendremos que aclarar xD. En todo caso, el proyecto sigue en marcha (aunque vaya más lento de lo deseable). Espero que para mayo tengamos algo lo suficientemente potable como para atraer algo de comunidad entorno a él. Saludos! El 30 de diciembre de 2009 02:17, Alejandro Alvarez < alv...@gm...> escribió: > Saludos Estimado Castarco ... > > Como siempre quisiera felicitarte por el enorme esfuerzo > que estas haciendo ... tanto Muammar como o estamos > siempre al pendiente de tu progreso ... y en particular > he estado estudiando tu código ... > > Quisiera preguntarte si hay la posibilidad de que hagamos > una reunión on-line ... podemos planificar la fecha ... > con el objetivo de que estudiemos juntos tu código ... o mejor > dicho, que nos des una clase xD pues has demostrado > ser un Maestro en Python ... > > Un abrazo, Feliz Navidad y Estamos en Contacto. > > Alejandro J. Alvarez S. > > P.D. Estamos contigo en este proyecto ... de manera un poco > pasiva ... pero te apoyaremos con todo lo que tengamos !!! > > > El 12 de diciembre de 2009 13:49, CaStarCo <cas...@gm...> escribió: > >> Perdon, di mal los comandos, que son (respectivamente para cada uno de >> los casos comentados): >> >> git pull origin reformed_styles_cache >> git pull origin without_styles_cache >> git pull origin master >> >> Voy a comentar brevemente el código que hice, pues ayer solo hice un >> anuncio demasiado escueto. >> >> Utilizando el módulo mmap de python se pueden hacer llamadas a la >> función de sistema mmap que sirve para mapear ficheros en memoria, en >> particular si se le pasa el descriptor de fichero -1 crea una área de >> memoria anónima no asociada a ningún fichero. Si ése área de memoria y >> el descriptor de fichero asociado se crean antes de hacer el fork , el >> descriptor de fichero es compartido por todos los ficheros, con lo que >> se puede usar esa área de memoria compartida para comunicar los >> procesos y establecer una cache comun... que es lo que hice. >> >> ¿Cuál es el problema? Pues que Python no da un soporte implícito a la >> compartición de objetos entre procesos por la misma razón que se >> implementó el GIL, para evitar los problemas de inseguridad inherentes >> al acceso concurrente a estructuras de datos en memoria... vamos, que >> Python no es thread-safe. Por eso mismo para poder mapear el >> diccionario que uso como cache en memoria tengo que usar el módulo >> pickle, que sirve para serializar objetos... tiene sus limitaciones, >> pero ya me sirve. El caso es que no he podido calcular las >> mejoras/empeoramientos de rendimiento debidos a ésta cache dado que no >> se me ocurre ningún metodo y no puedo someter tabularium a una carga >> intensiva de trabajo debido a que no hay usuarios. >> >> ¿A alguien se le ocurre un experimento decente que permita verificar >> si el rendimiento mejora o empeora? Bien, lo digo porque en principio >> sería de esperar que el rendimiento mejorara si no fuera por el hecho >> de que todo el proceso que sigo para tratar con la cache aumenta la >> intensidad de los cálculos (aunque nos libera de accesos a disco y >> comunicaciones con la base de datos, que podría ser remota). Es por >> eso que no tengo tan claro hasta qué punto eso supone una mejora... >> (aunque, ahora viene la sorpresa :D , agradable por cierto) >> >> A parte de los problemas que conlleva la creación de la cache tal y >> como he comentado hasta ahora, hay más, resulta que se debe calcular a >> priori un tamaño razonable para la cache... y eso depende mucho del >> funcionamiento interno de pickle (que podría variar con cada versión >> de Python), por lo que uno debe ser "generoso" y además esto hace que >> aparezcan "números mágicos" difíciles de justificar en medio del >> código (que provienen de la experimentación). No creo que sea una >> buena práctica de programación depender de esos "números mágicos". >> >> Y la alegría: he descubierto un método mejor xD. Y os preguntaréis... >> ¿y para que todo este rollo? Pues para que podáis apreciar por qué >> razón lo que sigue és obviamente mejor. ¿Alguien de por aquí sabe lo >> que és memcached? Bien, pues es un sistema que sirve para crear caches >> en memoria... pero obviamente mucho más optimizado de lo que yo haya >> podido hacer hasta el momento (en gran parte porque está creado en C y >> no en Python y porque los desarrolladores se han esmerado en ello y >> ese era su objetivo básico). Memcached funciona de la siguiente >> manera: se levanta un servidor que crea un área de memoria compartida >> del tamaño que se le indica durante su arranque, éste servidor está >> disponible a través de un puerto que también se especifica durante su >> arranque y sirve para almacenar objetos, no simples cadenas de la >> misma forma que yo lo hacía con mmap y pickle, sino los objetos en sí >> (se simplifica la gestión), y tratados con código optimizado escrito >> en C. Además se le puede asociar a cada objeto un tiempo de vida... lo >> que en parte serviría para eliminar código como el que yo usaba para >> eliminar los elementos más antiguos de la cache... pasa de ser código >> en Python a ser código altamente optimizado en C. >> >> Hay más ventajas, esa cache no solo sirve para el ejemplo de los >> estilos, puede ser una cache comun que se utilize para cualquier tipo >> de objeto, lo que simplifica en gran medida la gestión interna de >> tabularium de las caches de datos mantenidas en memoria. >> >> Entonces.. qué hay que hacer para utilizar memcached? En debian y >> ubunut: instalar memcached y python-memcache... el código lo podréis >> ver en breve en cuanto reemplaze la versión actual de tabularium con >> cache por la siguiente usando el servidor de memcached. >> >> Saludos! >> >> Referencias: >> [0] http://blog.isotoma.com/2009/09/memcache-in-2-minutes/ >> [1] >> http://blog.isotoma.com/2009/09/of-python-memcached-and-decorators-easy-peasy-function-caching/ >> >> P.D.: No estoy muy metido en GuPy, pero creo que es recomendable dar a >> conocer allí cosas como éstas: mmap, pickle, memcached, tornado ... >> >> El día 11 de diciembre de 2009 23:26, CaStarCo <cas...@gm...> >> escribió: >> > Bien, he creado dos ramas diferentes para tabularium, una con cache >> > para estilos y otra sin. La sin... sin novedades, vamos, sin cache y >> > punto. >> > >> > La con: he conseguido crear una cache compartida en memoria usando >> > mmap y el modulo pickle, podéis ver el código en los repos . Pero >> > teneis que hacer: >> > >> > para con cache: >> > git pull reformed_styles_cache >> > >> > sin cache: >> > git pull without_styles_cache >> > >> > sin eliminar la cache.. y con los bugs de antes: >> > git pull master >> > >> > Saludos! >> > >> > (Estaría bien testear a ver cual rinde más de las dos primeras.. (la >> > tercera queda descartada)) >> > >> > -- >> > - Per la llibertat del coneixement - >> > - Per la llibertat de la ment... - >> > >> >> >> >> -- >> - Per la llibertat del coneixement - >> - Per la llibertat de la ment... - >> >> >> ------------------------------------------------------------------------------ >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> Tabularium-devel mailing list >> Tab...@li... >> https://lists.sourceforge.net/lists/listinfo/tabularium-devel >> > > > > -- > Lic. Alejandro J. Alvarez S. > Linux Registered User #483871 > http://thedynamicist.wordpress.com > http://www.proyectociencia.org > http://alvarez.iblogger.org > +58-0416-1614095 > +58-0212-5041731 > -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-12-12 16:50:29
|
Perdon, di mal los comandos, que son (respectivamente para cada uno de los casos comentados): git pull origin reformed_styles_cache git pull origin without_styles_cache git pull origin master Voy a comentar brevemente el código que hice, pues ayer solo hice un anuncio demasiado escueto. Utilizando el módulo mmap de python se pueden hacer llamadas a la función de sistema mmap que sirve para mapear ficheros en memoria, en particular si se le pasa el descriptor de fichero -1 crea una área de memoria anónima no asociada a ningún fichero. Si ése área de memoria y el descriptor de fichero asociado se crean antes de hacer el fork , el descriptor de fichero es compartido por todos los ficheros, con lo que se puede usar esa área de memoria compartida para comunicar los procesos y establecer una cache comun... que es lo que hice. ¿Cuál es el problema? Pues que Python no da un soporte implícito a la compartición de objetos entre procesos por la misma razón que se implementó el GIL, para evitar los problemas de inseguridad inherentes al acceso concurrente a estructuras de datos en memoria... vamos, que Python no es thread-safe. Por eso mismo para poder mapear el diccionario que uso como cache en memoria tengo que usar el módulo pickle, que sirve para serializar objetos... tiene sus limitaciones, pero ya me sirve. El caso es que no he podido calcular las mejoras/empeoramientos de rendimiento debidos a ésta cache dado que no se me ocurre ningún metodo y no puedo someter tabularium a una carga intensiva de trabajo debido a que no hay usuarios. ¿A alguien se le ocurre un experimento decente que permita verificar si el rendimiento mejora o empeora? Bien, lo digo porque en principio sería de esperar que el rendimiento mejorara si no fuera por el hecho de que todo el proceso que sigo para tratar con la cache aumenta la intensidad de los cálculos (aunque nos libera de accesos a disco y comunicaciones con la base de datos, que podría ser remota). Es por eso que no tengo tan claro hasta qué punto eso supone una mejora... (aunque, ahora viene la sorpresa :D , agradable por cierto) A parte de los problemas que conlleva la creación de la cache tal y como he comentado hasta ahora, hay más, resulta que se debe calcular a priori un tamaño razonable para la cache... y eso depende mucho del funcionamiento interno de pickle (que podría variar con cada versión de Python), por lo que uno debe ser "generoso" y además esto hace que aparezcan "números mágicos" difíciles de justificar en medio del código (que provienen de la experimentación). No creo que sea una buena práctica de programación depender de esos "números mágicos". Y la alegría: he descubierto un método mejor xD. Y os preguntaréis... ¿y para que todo este rollo? Pues para que podáis apreciar por qué razón lo que sigue és obviamente mejor. ¿Alguien de por aquí sabe lo que és memcached? Bien, pues es un sistema que sirve para crear caches en memoria... pero obviamente mucho más optimizado de lo que yo haya podido hacer hasta el momento (en gran parte porque está creado en C y no en Python y porque los desarrolladores se han esmerado en ello y ese era su objetivo básico). Memcached funciona de la siguiente manera: se levanta un servidor que crea un área de memoria compartida del tamaño que se le indica durante su arranque, éste servidor está disponible a través de un puerto que también se especifica durante su arranque y sirve para almacenar objetos, no simples cadenas de la misma forma que yo lo hacía con mmap y pickle, sino los objetos en sí (se simplifica la gestión), y tratados con código optimizado escrito en C. Además se le puede asociar a cada objeto un tiempo de vida... lo que en parte serviría para eliminar código como el que yo usaba para eliminar los elementos más antiguos de la cache... pasa de ser código en Python a ser código altamente optimizado en C. Hay más ventajas, esa cache no solo sirve para el ejemplo de los estilos, puede ser una cache comun que se utilize para cualquier tipo de objeto, lo que simplifica en gran medida la gestión interna de tabularium de las caches de datos mantenidas en memoria. Entonces.. qué hay que hacer para utilizar memcached? En debian y ubunut: instalar memcached y python-memcache... el código lo podréis ver en breve en cuanto reemplaze la versión actual de tabularium con cache por la siguiente usando el servidor de memcached. Saludos! Referencias: [0] http://blog.isotoma.com/2009/09/memcache-in-2-minutes/ [1] http://blog.isotoma.com/2009/09/of-python-memcached-and-decorators-easy-peasy-function-caching/ P.D.: No estoy muy metido en GuPy, pero creo que es recomendable dar a conocer allí cosas como éstas: mmap, pickle, memcached, tornado ... El día 11 de diciembre de 2009 23:26, CaStarCo <cas...@gm...> escribió: > Bien, he creado dos ramas diferentes para tabularium, una con cache > para estilos y otra sin. La sin... sin novedades, vamos, sin cache y > punto. > > La con: he conseguido crear una cache compartida en memoria usando > mmap y el modulo pickle, podéis ver el código en los repos . Pero > teneis que hacer: > > para con cache: > git pull reformed_styles_cache > > sin cache: > git pull without_styles_cache > > sin eliminar la cache.. y con los bugs de antes: > git pull master > > Saludos! > > (Estaría bien testear a ver cual rinde más de las dos primeras.. (la > tercera queda descartada)) > > -- > - Per la llibertat del coneixement - > - Per la llibertat de la ment... - > -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-12-11 22:26:47
|
Bien, he creado dos ramas diferentes para tabularium, una con cache para estilos y otra sin. La sin... sin novedades, vamos, sin cache y punto. La con: he conseguido crear una cache compartida en memoria usando mmap y el modulo pickle, podéis ver el código en los repos . Pero teneis que hacer: para con cache: git pull reformed_styles_cache sin cache: git pull without_styles_cache sin eliminar la cache.. y con los bugs de antes: git pull master Saludos! (Estaría bien testear a ver cual rinde más de las dos primeras.. (la tercera queda descartada)) -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: Muammar El K. <mu...@pr...> - 2009-12-10 00:00:23
|
Hola, 2009/12/9 CaStarCo <cas...@gm...>: > Experimentando con la cache he visto que no da tan buenos resultados > como sería deseable por las siguientes razones: > > · Dado que Tabularium és un programa multiproceso (y no multihilo), > los procesos están prácticamente incomunicados y no tienen áreas de > memoria compartida (habría que usar algo más avanzado como MPI... pero > creo que eso sería complicar demasiado las cosas). Nginx funciona de No creo que sea necesario, usar MPI ni nada de eso en este momento pero si tenerlo en mente (ya más abajo dejaré en claro el por qué digo que hay que mantenerlo en mente). Me parece muy bien que de partida te estés preocupando por hacer la aplicación lo más rápida y eficiente posible. Yo te voy a hablar desde el punto de vista de administrador de sistemas, que es la experiencia que más he tenido recientemente (doy consultoría a una empresa que tiene un servicio web bastante demandado). El que un servidor pueda operar correctamente con una aplicación Web depende de muchas cosas. El hacer llamadas o consultas inútiles a la base de datos es algo que desmejora mucho el rendimiento y respuesta de un servidor. El uso de caché también es muy importante, aunque yo no he podido medir nada al respecto. Pero hay que ver qué se sacrifica con ello. Te puedo comentar que un servidor con procesador Intel Quad Core con un arreglo RAID 5 y 4GB de RAM puede manejar sin problemas al menos unas 350 conexiones recurrentes y mantener la eficiencia en las respuestas de manera aceptable. Y te estoy hablando de una página hecha en PHP que usa como base de datos MySQL. Hay incluso alguna serie de cálculos propuestos para calcular esto así como también aplicaciones que te permiten estresar un servidor para tener un aproximado real del comportamiento en escenarios críticos. Otros factores pueden gobernar la eficiencia de una aplicación Web. Supongamos que en el plano ideal, la aplicación está bien hecha en un 90%. Es instalada en un servidor con 12GB de RAM. Pero dicho servidor: 1) No posee una buena configuración de la base de datos. 2) No posee una configuración adecuada del servidor web. 3) Un sistema de archivo no adecuado. Todos estos factores afectan de manera tal la aplicación que esta es "perfecta", el performance se va al suelo. Creo que se evitará mucho este escenario porque tu te estás enfocando en el performance y buen uso de los recursos. Pero hasta que no se implemente en una situación como la descrita, no sabremos con seguridad cómo depurar ese problema. > manera que va rotando los procesos que se encargan de servir las > páginas a los usuarios (con el algoritmo Round Robin) y puede pasar > que se tenga que rellenar la caché tantas veces como procesos haya por > cada usuario (una vez por cada proceso a cada actualización, siempre > que se el proceso que sirva al usuario X no le haya servido nada > antes). > > Supongo que utilizar una cache en memoria puede ser muy útil para > ciertas cosas, pero por lo que respecta a almacenar cadenas cortas de > texto (que es lo que hize en el experimento), acaba siendo una > complicación innecesaria que prácticamente no aporta una mejora de > rendimiento sustancial frente al incremento del consumo de memoria. > El uso de memoria RAM debe ser consciente. El restar mucha memoria RAM a un servidor va a traer como consecuencia que la respuesta de servir páginas se haga mucho menor. > Para postres, cuando el usuario actualiza sus preferencias puede tener > problemas ya que si ha rellenado las caches de varis procesos, no las > actualiza todas (solo la del proceso que estaba funcionando en el > momento del cambio de preferencias), por lo que a cada actualización o > cambio de página podrá ver como sus preferencias se alternan entre sus > preferencias antiguas y las configuradas recientemente. Para > solucionar eso solo hay una medida: purgar las caches cada cierto > tiempo... pero es puede eliminar los beneficios de ésta. > Sí. Se eliminarían los beneficios del uso del caché. > Conclusión: eliminaré el sistema de cache (por el momento), por ahora > ha servido para experimentar, conocer los problemas inherentes a esta > forma de proceder y poder aplicar lo aprendido a nuevos intentos que > tengan más interés que el simple sistema de estilos. Otra conclusión > es que sería interesante estudiar el funcionamiento de sistemas como > MPI o funciones como mmap que permiten mapear ficheros en memoria para > usarlos a modo de canales de transmisión de información para comunicar > procesos. (Como las pipes, pero de acceso aleatorio en vez de ser > colas) > Me parece bien que por los momentos se haya decido dejar de un lado el tema del caché sino solo para lo necesario. La mayoría de los proveedores de servicios grandes usan clusters para los servidores web (yo se que lo sabes, solo lo escribo para que quede en los archivos). Por ejemplo, en el caso de tabularium sería: 1) Una máquina para la base de datos. 2) Una máquina para contener los libros. 3) Una máquina donde se aloja la página principal. De esa forma se distribuiría la carga. Lo que no tengo ni idea es de cómo implementar un cluser Web, tampoco estoy seguro si utilizan el protocolo MPI u otro, habría que investigarlo. > Para finalizar, mis disculpas por transformar el desarrollo de > tabularium en un campo de experimentación y hacer que tarde el doble > de lo necesario, pero realmente me gustaría conseguir un software que > pueda comportarse de forma ejemplar ante cargas de trabajo > descomunales. > No, no debes disculparte por eso. Creo que no importa lo rápido que se haga, pero si lo bien. Calidad... Saludos, -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- |
From: Muammar El K. <mu...@pr...> - 2009-12-09 23:38:22
|
Hola, 2009/12/9 CaStarCo <cas...@gm...>: > Bién, he añadido el sistema de estilos. Hay un estilo por defecto y > cada usuario puede escoger su estilo (bién, no tienen ningun menú > todavía pero ya está implementado el mecanismo y funciona > correctamente). De hecho he creado una pequeña cache en memoria que > almacena las preferencias de estilo de cada usuario con una marca de > tiempo para evitar hacer demasiados accesos a la base de datos.. (que > sí, ya sé que tiene también una cache en memoria pero no podemos estar > seguros de que siempre la vaya a usar). > Esto es bueno, el hecho de que se puedan escoger estilos. > Nota: recomiendo crear una rama aparte cada vez que estemos > desarrollando o haciendo cambios en el repositorio, luego si acaso > hacemos un merge :p , lo digo porque me he encontrado con problemas > para subir mis cambios pues no tenía actualizado el repositorio y > Muammar ha hecho cambios mientras tanto jejeje (en todo caso ya está > arreglado). > Deberíamos crear en algún lugar *todo* el procedimiento correcto para hacer los commits sin entorpecer el desarrollo y la integridad del mismo :S Saludos, -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- |
From: CaStarCo <cas...@gm...> - 2009-12-09 21:15:28
|
Experimentando con la cache he visto que no da tan buenos resultados como sería deseable por las siguientes razones: · Dado que Tabularium és un programa multiproceso (y no multihilo), los procesos están prácticamente incomunicados y no tienen áreas de memoria compartida (habría que usar algo más avanzado como MPI... pero creo que eso sería complicar demasiado las cosas). Nginx funciona de manera que va rotando los procesos que se encargan de servir las páginas a los usuarios (con el algoritmo Round Robin) y puede pasar que se tenga que rellenar la caché tantas veces como procesos haya por cada usuario (una vez por cada proceso a cada actualización, siempre que se el proceso que sirva al usuario X no le haya servido nada antes). Supongo que utilizar una cache en memoria puede ser muy útil para ciertas cosas, pero por lo que respecta a almacenar cadenas cortas de texto (que es lo que hize en el experimento), acaba siendo una complicación innecesaria que prácticamente no aporta una mejora de rendimiento sustancial frente al incremento del consumo de memoria. Para postres, cuando el usuario actualiza sus preferencias puede tener problemas ya que si ha rellenado las caches de varis procesos, no las actualiza todas (solo la del proceso que estaba funcionando en el momento del cambio de preferencias), por lo que a cada actualización o cambio de página podrá ver como sus preferencias se alternan entre sus preferencias antiguas y las configuradas recientemente. Para solucionar eso solo hay una medida: purgar las caches cada cierto tiempo... pero es puede eliminar los beneficios de ésta. Conclusión: eliminaré el sistema de cache (por el momento), por ahora ha servido para experimentar, conocer los problemas inherentes a esta forma de proceder y poder aplicar lo aprendido a nuevos intentos que tengan más interés que el simple sistema de estilos. Otra conclusión es que sería interesante estudiar el funcionamiento de sistemas como MPI o funciones como mmap que permiten mapear ficheros en memoria para usarlos a modo de canales de transmisión de información para comunicar procesos. (Como las pipes, pero de acceso aleatorio en vez de ser colas) Para finalizar, mis disculpas por transformar el desarrollo de tabularium en un campo de experimentación y hacer que tarde el doble de lo necesario, pero realmente me gustaría conseguir un software que pueda comportarse de forma ejemplar ante cargas de trabajo descomunales. El día 9 de diciembre de 2009 12:12, CaStarCo <cas...@gm...> escribió: > Bién, he añadido el sistema de estilos. Hay un estilo por defecto y > cada usuario puede escoger su estilo (bién, no tienen ningun menú > todavía pero ya está implementado el mecanismo y funciona > correctamente). De hecho he creado una pequeña cache en memoria que > almacena las preferencias de estilo de cada usuario con una marca de > tiempo para evitar hacer demasiados accesos a la base de datos.. (que > sí, ya sé que tiene también una cache en memoria pero no podemos estar > seguros de que siempre la vaya a usar). > > Nota: recomiendo crear una rama aparte cada vez que estemos > desarrollando o haciendo cambios en el repositorio, luego si acaso > hacemos un merge :p , lo digo porque me he encontrado con problemas > para subir mis cambios pues no tenía actualizado el repositorio y > Muammar ha hecho cambios mientras tanto jejeje (en todo caso ya está > arreglado). > > -- > - Per la llibertat del coneixement - > - Per la llibertat de la ment... - > -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-12-09 11:12:59
|
Bién, he añadido el sistema de estilos. Hay un estilo por defecto y cada usuario puede escoger su estilo (bién, no tienen ningun menú todavía pero ya está implementado el mecanismo y funciona correctamente). De hecho he creado una pequeña cache en memoria que almacena las preferencias de estilo de cada usuario con una marca de tiempo para evitar hacer demasiados accesos a la base de datos.. (que sí, ya sé que tiene también una cache en memoria pero no podemos estar seguros de que siempre la vaya a usar). Nota: recomiendo crear una rama aparte cada vez que estemos desarrollando o haciendo cambios en el repositorio, luego si acaso hacemos un merge :p , lo digo porque me he encontrado con problemas para subir mis cambios pues no tenía actualizado el repositorio y Muammar ha hecho cambios mientras tanto jejeje (en todo caso ya está arreglado). -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-12-09 10:01:51
|
Un mensaje de la lista de tornado :) , en cuanto liberen la nueva versión cambiaré el código y quedará simplificado :D , simplemente detectará el número de procesadores de forma automática y creará un proceso independiente por cada uno de ellos ^^. Además compartirán puertos, así que que nginx no tendrá que perder tiempo balanceando carga y de ello se encargará el kernel. ---------- Forwarded message ---------- From: Bret Taylor <bt...@gm...> Date: 2009/12/9 Subject: Run Tornado servers on all available CPUs with pre-forking To: pyt...@go... I just checked in a (experimental and backwards-compatible) change to enable "pre-forking" Tornado servers, and I would love your feedback: http://github.com/facebook/tornado/commit/6fb90ae694190fcedc48d9fb98b02325826d783e Previously, every Tornado server ran on a single thread within a single process. If your server had 8 cores, you would have to run 8 separate Tornado processes on 8 different ports to utilize all CPUs and put a reverse proxy like nginx in front to balance requests between all those processes (see http://www.tornadoweb.org/documentation#running-tornado-in-production). With this change, you can easily run a single Tornado server listening to a single port on all available CPUs of a server. To try out this change, change your call from listen(port) to bind(port) followed by start(), e.g., http_server = tornado.httpserver.HTTPServer(application) http_server.bind(options.port) http_server.start() # Pre-forks multiple child processes tornado.ioloop.IOLoop.instance().start() start() detects the number of CPUs on the current machine and "pre-forks" that number of child processes so that we have one Tornado process per CPU, all with their own IOLoop. You can also pass in the specific number of child processes you want to run with if you want to override this auto-detection. listen(port) is simply a shortcut for bind(port); start(1). Background The "pre-forking" phrase is used to mean a couple of different things, so it is worth clarifying what it means for Tornado. Essentially, we bind a single server socket to a port, and we fork() one process per CPU. Each of those CPUs calls accept() on the shared server socket, and the Linux kernel gives new requests to one of the child processes on a first-come-first-serve basis. Each of the child processes has their own epoll-based IO loop, and a single request is handled entirely within one of the child processes. There is no shared memory or shared state between the forked child processes, only a shared port. This technique is used by a number of high performance servers, including Unicorn (see http://tomayko.com/writings/unicorn-is-unix). Apache pre-forking means something entirely different (forking a process for each request), so please don't get confused if you Google "pre-forking" and see people talking about the performance characteristics of Apache. Bret -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-12-09 06:16:30
|
Buenas, El 9 de diciembre de 2009 00:13, Muammar El Khatib <mu...@pr...> escribió: > > Se podría probar. Ahora no me queda claro algo. ¿Estás usando el > repositorio git de sf.net o de gitorious? Los dos a la vez :) , el de gitorious es como una copia de seguridad más En cuanto al redireccionamiento "limpio" al que hacía referencia... no es posible, los datos no se pueden pasar por POST. En todo caso se deben usar cookies o variables de sesión... o lo que se está haciendo hasta ahora. En cuanto al almacenamiento de ficheros: Sabiendo como funciona un inode en un sistema de ficheros UNIX-like, se puede determinar la cantidad de ficheros por directorio para la que la velocidad media de acceso empezará a decrecer (depende de las tablas de direcciones e indirecciones del inode), así pues, si un directorio está cargado con miles de ficheros la velocidad media de acceso descenderá y puede que sea más conveniente añadir subdirectorios. Es por eso que la profundidad de la "ramificación" debe depender del sistema de ficheros y la cantidad de ficheros disponibles en el repositorio... y tendría que ser dinámica, puede que cada cierto tiempo fuera necesario un reajuste (si el crecimiento de la biblioteca fuera muy grande, claro). Esas ramificaciones se harían del mismo modo que comenté anteriormente: a partir de los dígitos del hash del fichero, de forma que la organización siempre sería relativamente homogénea :) . En todo caso, es un asunto digno de estudio, hay muchas variables importantes que afectan al rendimiento: longitud de la ruta (más iempo de procesador), cantidad de indirecciones que hay que realizar (proporcional al numero de subdirectorios incrustados uno dentro de otro) (más tiempo de acceso a disco), número de ficheros en el repositorio (más tiempo de acceso a disco si crece demasiado i no se ramifican bien los directorios)... se tienen que considerar muchas cosas y hacer muchos cálculos previos y experimentos (y lo que es "peor", me temo que para cada máquina pueden hacer falta parámetros muy diferentes). Bien, eso es todo, me voy a clase :) . -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: Muammar El K. <mu...@pr...> - 2009-12-08 23:11:45
|
Hola, 2009/12/1 CaStarCo <cas...@gm...>: > He mejorado el sistema de login y he añadido información referente a la base > de datos (aunque aun no la uso al 100%), también he añadido documentación > referente al almacenamiento de libros digitales, estaría bien discutir la > forma, pues si queremos que escale debemos poder distribuír la carga de > almacenamiento y accesos. > Esto sería bueno discutirlo en otro hilo. > He propuesto un sistema en el que el almacen está subdividido en arbol de > directorios con un grado de ramificación 16 , todas los directorios y > subdirectorios nombrados con las letras 0, 1, 2, ..., 9, a, b, .., f. Cada > fichero iría a una carpeta u otra dependiendo de su valor md5 (que quedaría > guardado dentro de la DB), dado que la distribución de las imagenes para la > función md5 es homogenea, se puede esperar que los libros estén repartidos > de forma más o menos homogénea. > ¿Entonces lo que sugieres es ingresar al archivo los libros según la primera letra o dígito de su valor md5? > Separar los libros en diferentes directorios, por un lado aporta cierto > orden, (aunque no sea inteligible para un ser humano que lo examine a ojo de > buen cubero), y por otro abre las puertas a montar diferentes sistemas de > archivos existentes en máquinas remotas, lo que serviría para distribuír la > carga tal y como indicaba en un principio. > Eso sí. Es posible montar cada letra/dígito en una partición distinta. > Lo que no sé es como lo haríamos para (en un futuro lejano) hacer que el > frontend (nginx, cherokee, o apache) no se transforme en un cuello de > botella. Ahora mismo el sistema está ideado para correr entre unas 2 y 8 > instancias de tabularium (una por procesador o núcleo) que actuan como > backend de nginx, que se encarga de distribuír la carga y de servir los > ficheros estáticos (para lo que está mucho mejor diseñado que tornado, que > tiene un mejor desempeño para las aplicaciones dinámicas como tabularium). > Esto lo veremos a lo que se implemente el software. El cuello de botella que se podría generar no solo depende de la aplicación si no también de la configuración del servidor (ya sea nginx, cherokee, o apache2). > El problema que veo a la larga (y supongo que me parece un problema por > falta de conocimientos.. seguro que hay alguna solución, si no los de > google, wikipedia u otros servicios de uso masivo no podrían con nada) es... > vale, toda la carga de tratamiento de la información está bien repartida... > pero ¿y qué pasa con la carga que tiene que soportar el intermediario > (nginx)? ¿como se distribuye la carga ligada a la transferencia de datos? > Aquí estoy yendo muy lejos ya, pero creo que es interesante plantearse la > cuestión. > Estas son buenas preguntas, pero cada servicio trae consigo la necesidad de distintas soluciones. La mayoría de esas empresas y organizaciones que nombraste tienen que hacer modificaciones desde cambiar algo en el kernel para mejorar el manejo de los recursos del hardware hasta cambiar la aplicación misma. > Por cierto, cosas que faltan y son sencillas, si queréis hacer algun apaño: > · Mejorar la seguridad en los formularios para hacerlos resistentes a SQL > injection (ya son resistentes, en teoría, a ataques xsrf) Se puede investigar, sería bueno reportar ese error en el BTS de tabularium porque si no todo se quedará en un correo. > · crear scripts que permitan una puesta a punto rápida del sistema para > reducir el tiempo de preparación y permitir que más gente pueda colaborar > IDEM. Saludos, -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- |
From: CaStarCo <cas...@gm...> - 2009-12-08 17:37:02
|
Mensaje perdido 4 ---------- Mensaje reenviado ---------- De: CaStarCo <cas...@gm...> Fecha: 8 de diciembre de 2009 15:14 Asunto: Re: [Tabularium-devel] Algo más usable Para: Alejandro Alvarez <alv...@gm...> Novedades del día: - He modificado la base de datos para añadir a la tabla de libros qué usuario lo ha subido al sistema - He especificado el sistema de permisos, ahora hay 4 categorías de usuario: Superadministrador, administrador, bibliotecario y usuario raso. - He añadido una página para que los usuarios puedan gestionar su información y ver cuántos libros han subido. - Los usuarios también pueden ver información (restringida) de los otros usuarios (rango y qué libros han subido). -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-12-08 17:36:31
|
Mensaje perdido 3 ---------- Mensaje reenviado ---------- De: CaStarCo <cas...@gm...> Fecha: 7 de diciembre de 2009 17:29 Asunto: Re: [Tabularium-devel] Algo más usable Para: Alejandro Alvarez <alv...@gm...> Bien, antes de continuar el estudio de ecuaciones diferenciales, un post con algunas novedades sobre tabularium: - He solucionado un "bug" del sistema de conexión a la base de datos, en principio creía que había conseguido que la conexión fuera persistente para que los accesos a la base de datos fueran más rápidos, pero había entendido mal la arquitectura de Tornado. Por lo tanto ahora sí que se puede decir que la conexión a la base de datos es persistente :) y eso acelerará los accesos! - De rebote, al solucionar el bug anterior he conseguido que la conexión persistente a la base de datos que en teoría solo estaba dedicada al subsistema de login sea usable por toda la aplicación :) . Saludos! -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-12-08 17:36:16
|
Mensaje perdido 2 ---------- Mensaje reenviado ---------- De: CaStarCo <cas...@gm...> Fecha: 6 de diciembre de 2009 23:53 Asunto: Re: [Tabularium-devel] Algo más usable Para: Alejandro Alvarez <alv...@gm...> Saludos otra vez :) . No he hecho mucho más... pero ahí va: 1. he seguido peleándome con el sistema de login, que ha mejorado algo más. Sí, parece estraño que se pueda mejorar tantas veces seguidas... pues es cierto, hay muhos detallitos que se tienen que ir puliendo, y había decidido pulirlos antes de continuar porque va a ser algo que use mucho en mis pruebas, por lo que quería que almenos fuera cómodo de usar. 2. He añadido código para que las tablas de la base de datos tengan un prefijo que se decide durante la instalación del sistema, con el objetivo de que los atacantes no conozcan el nombre completo de las tablas y limitar la incidencia de posibles ataques por SQL injection en caso de que tengamos algún despiste. Apuntes: Si alguien descubre como hacer redirecciones limpias en las que pueda pasar parámetros por POST en vez de por GET... (miraos el código del módulo login_handler) , sería muy bueno para mantener urls limpias :) . Sigue siendo interesante la idea de crear scripts que faciliten la instalación de tabularium.. supongo que los acabaré haciendo yo, pero si queréis provar, sería muy útil para acelerar el proceso de desarrollo :) . Saludos! -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-12-08 17:35:46
|
Desgraciadamente una lista enorme de emails salieron de la lista... :s ---------- Mensaje reenviado ---------- De: Alejandro Alvarez <alv...@gm...> Fecha: 2 de diciembre de 2009 14:06 Asunto: Re: [Tabularium-devel] Algo más usable Para: CaStarCo <cas...@gm...> Saludos, Excelentes noticias ... de verdad es impresionante !!! Cuando piensas que podremos emigrar a una primera version de Tabularium? El 2 de diciembre de 2009 19:26, CaStarCo <cas...@gm...> escribió: > He mejorado el sistema de login y he añadido información referente a la > base de datos (aunque aun no la uso al 100%), también he añadido > documentación referente al almacenamiento de libros digitales, estaría bien > discutir la forma, pues si queremos que escale debemos poder distribuír la > carga de almacenamiento y accesos. > > He propuesto un sistema en el que el almacen está subdividido en arbol de > directorios con un grado de ramificación 16 , todas los directorios y > subdirectorios nombrados con las letras 0, 1, 2, ..., 9, a, b, .., f. Cada > fichero iría a una carpeta u otra dependiendo de su valor md5 (que quedaría > guardado dentro de la DB), dado que la distribución de las imagenes para la > función md5 es homogenea, se puede esperar que los libros estén repartidos > de forma más o menos homogénea. > > Separar los libros en diferentes directorios, por un lado aporta cierto > orden, (aunque no sea inteligible para un ser humano que lo examine a ojo de > buen cubero), y por otro abre las puertas a montar diferentes sistemas de > archivos existentes en máquinas remotas, lo que serviría para distribuír la > carga tal y como indicaba en un principio. > > Lo que no sé es como lo haríamos para (en un futuro lejano) hacer que el > frontend (nginx, cherokee, o apache) no se transforme en un cuello de > botella. Ahora mismo el sistema está ideado para correr entre unas 2 y 8 > instancias de tabularium (una por procesador o núcleo) que actuan como > backend de nginx, que se encarga de distribuír la carga y de servir los > ficheros estáticos (para lo que está mucho mejor diseñado que tornado, que > tiene un mejor desempeño para las aplicaciones dinámicas como tabularium). > > El problema que veo a la larga (y supongo que me parece un problema por > falta de conocimientos.. seguro que hay alguna solución, si no los de > google, wikipedia u otros servicios de uso masivo no podrían con nada) es... > vale, toda la carga de tratamiento de la información está bien repartida... > pero ¿y qué pasa con la carga que tiene que soportar el intermediario > (nginx)? ¿como se distribuye la carga ligada a la transferencia de datos? > Aquí estoy yendo muy lejos ya, pero creo que es interesante plantearse la > cuestión. > > Por cierto, cosas que faltan y son sencillas, si queréis hacer algun apaño: > · Mejorar la seguridad en los formularios para hacerlos resistentes a SQL > injection (ya son resistentes, en teoría, a ataques xsrf) > · crear scripts que permitan una puesta a punto rápida del sistema para > reducir el tiempo de preparación y permitir que más gente pueda colaborar > > Saludos! > > -- > - Per la llibertat del coneixement - > - Per la llibertat de la ment... - > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Tabularium-devel mailing list > Tab...@li... > https://lists.sourceforge.net/lists/listinfo/tabularium-devel > > -- Lic. Alejandro J. Alvarez S. Linux Registered User #483871 http://thedynamicist.wordpress.com http://www.proyectociencia.org http://alvarez.iblogger.org +58-0416-1614095 +58-0212-5041731 -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-12-01 23:56:34
|
He mejorado el sistema de login y he añadido información referente a la base de datos (aunque aun no la uso al 100%), también he añadido documentación referente al almacenamiento de libros digitales, estaría bien discutir la forma, pues si queremos que escale debemos poder distribuír la carga de almacenamiento y accesos. He propuesto un sistema en el que el almacen está subdividido en arbol de directorios con un grado de ramificación 16 , todas los directorios y subdirectorios nombrados con las letras 0, 1, 2, ..., 9, a, b, .., f. Cada fichero iría a una carpeta u otra dependiendo de su valor md5 (que quedaría guardado dentro de la DB), dado que la distribución de las imagenes para la función md5 es homogenea, se puede esperar que los libros estén repartidos de forma más o menos homogénea. Separar los libros en diferentes directorios, por un lado aporta cierto orden, (aunque no sea inteligible para un ser humano que lo examine a ojo de buen cubero), y por otro abre las puertas a montar diferentes sistemas de archivos existentes en máquinas remotas, lo que serviría para distribuír la carga tal y como indicaba en un principio. Lo que no sé es como lo haríamos para (en un futuro lejano) hacer que el frontend (nginx, cherokee, o apache) no se transforme en un cuello de botella. Ahora mismo el sistema está ideado para correr entre unas 2 y 8 instancias de tabularium (una por procesador o núcleo) que actuan como backend de nginx, que se encarga de distribuír la carga y de servir los ficheros estáticos (para lo que está mucho mejor diseñado que tornado, que tiene un mejor desempeño para las aplicaciones dinámicas como tabularium). El problema que veo a la larga (y supongo que me parece un problema por falta de conocimientos.. seguro que hay alguna solución, si no los de google, wikipedia u otros servicios de uso masivo no podrían con nada) es... vale, toda la carga de tratamiento de la información está bien repartida... pero ¿y qué pasa con la carga que tiene que soportar el intermediario (nginx)? ¿como se distribuye la carga ligada a la transferencia de datos? Aquí estoy yendo muy lejos ya, pero creo que es interesante plantearse la cuestión. Por cierto, cosas que faltan y son sencillas, si queréis hacer algun apaño: · Mejorar la seguridad en los formularios para hacerlos resistentes a SQL injection (ya son resistentes, en teoría, a ataques xsrf) · crear scripts que permitan una puesta a punto rápida del sistema para reducir el tiempo de preparación y permitir que más gente pueda colaborar Saludos! -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-11-29 13:00:45
|
He añadido algunos cambios extras y he clonado el repositorio a gitorious para que se pueda acceder más fácilmente (sourceforge es un poco lento y se hace pesado navegar por su estructura). -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-11-29 11:53:53
|
Buenas :) , todavía no he hecho que tabularium sea útil, ni mucho menos, pero ya existe una micro estructura visible que puede ayudar a ver por donde van los tiros. De momento lo estoy planteando para que funcione conjuntamente con servidores ligeros tales com nginx o cherokee (estoy haciendo las pruebas con nginx). Se pueden ejecutar varias instancias concurrentemente (para aprovechar la capacidad de los sistemas con múltiples procesadores) de forma que el servidor de ficheros estáticos (en mi caso nginx, pero podría ser Cherokee o Apache actúe como balanceador de carga entre las diferentes instancias de Tabularium). Podéis ver el código en el repositorio git de sourceforge :) . Ahora estoy planteando el asunto de la configuración y la base de datos. Por el momento la configuración básica se guarda en un fichero /etc/tabularium/tabularium.conf (mucho más seguro que el típico sistema visto con php), allí habría los datos de conexión y todo eso.. y no sé si usar una capa de abstracción para las conexiones con la base de datos (y así poder cambiarla) o escoger una directamente. (Esta decisión tiene impactos sobre el rendimiento, a más abstracción y encapsulación, menor rendimiento, pero mayor la flexibilidad). Espero comentarios, saludos! -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-11-03 18:47:16
|
Buenas otra vez, después de haber leído un artículo sobre programación con Tornado he decidido que dejaré de lado PHP y lo haré directamente en Python tal y como acordamos al principio, solo que utilizaré el proyecto Tornado liberado por FriendFeed hace poco, la programación es muy sencilla y es muy fácil iniciar un servidor con él :) con una capacidad de carga enorme. Para los que queráis os puedo pasar un pdf de Linux Magazine en el que se explica brevemente como programar con Tornado. No lo paso por aquí porque está sujeto a derechos de autor y tampoco me haría gracia empezar a diseminarlo, no sé si tiene alguna marca de agua o algo por el estilo que me identifique a mi particularmente como el que ha descargado éste fichero y luego lo ha distribuído, no tengo ganas de comprovarlo jeje. El 3 de noviembre de 2009 02:00, Muammar El Khatib < mu...@pr...> escribió: > 2009/11/2 CaStarCo <cas...@gm...>: > > Este jueves y viernes tendré bastante tiempo libre y intentaré dedicar un > > poco de éste a hacer un prototipo útil para Tabularium, creo que con poco > > que haga conseguiré un sistema más cómodo que el que tenemos actualmente > > para gestionar la biblioteca. Como busco resultados rápidos lo programaré > en > > php ya que no tendré que configurar nada en el servidor para ejecutarlo > (a > > excepción de la base de datos), en todo caso, dado que será un prototipo > > siempre se puede volver a Python si lo consideráis oportuno. > > Saludos! > > > > Muchas gracias por esto. Mantennos informados. > > Saludos, > > > -- > Muammar El Khatib. > Linux user: 403107. > GPG Key = 127029F1 > http://muammar.me | http://proyectociencia.org > ,''`. > : :' : > `. `' > `- > -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: Muammar El K. <mu...@pr...> - 2009-11-03 01:01:00
|
2009/11/2 CaStarCo <cas...@gm...>: > Este jueves y viernes tendré bastante tiempo libre y intentaré dedicar un > poco de éste a hacer un prototipo útil para Tabularium, creo que con poco > que haga conseguiré un sistema más cómodo que el que tenemos actualmente > para gestionar la biblioteca. Como busco resultados rápidos lo programaré en > php ya que no tendré que configurar nada en el servidor para ejecutarlo (a > excepción de la base de datos), en todo caso, dado que será un prototipo > siempre se puede volver a Python si lo consideráis oportuno. > Saludos! > Muchas gracias por esto. Mantennos informados. Saludos, -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- |
From: CaStarCo <cas...@gm...> - 2009-11-02 21:13:58
|
Este jueves y viernes tendré bastante tiempo libre y intentaré dedicar un poco de éste a hacer un prototipo útil para Tabularium, creo que con poco que haga conseguiré un sistema más cómodo que el que tenemos actualmente para gestionar la biblioteca. Como busco resultados rápidos lo programaré en php ya que no tendré que configurar nada en el servidor para ejecutarlo (a excepción de la base de datos), en todo caso, dado que será un prototipo siempre se puede volver a Python si lo consideráis oportuno. Saludos! -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |
From: CaStarCo <cas...@gm...> - 2009-08-26 06:14:38
|
Inicializando la lista de correo para el proyecto Tabularium. -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - |