From joel.pinckheardagmail.com Fri Jun 1 15:06:41 2007 From: joel.pinckheardagmail.com (Joel Pinckheard) Date: Sat, 2 Jun 2007 00:06:41 +0200 Subject: [bcn-pm] Test mail.pm.org Message-ID: <391e184c0706011506p71d41425k45da3bbc65853389@mail.gmail.com> -- Joel Pinckheard http://www.pincky.com/ From joel.pinckheardagmail.com Fri Jun 1 15:07:05 2007 From: joel.pinckheardagmail.com (Joel Pinckheard) Date: Sat, 2 Jun 2007 00:07:05 +0200 Subject: [bcn-pm] Test pm.org Message-ID: <391e184c0706011507m6af6de83vdad664ab0adb8f3e@mail.gmail.com> -- Joel Pinckheard http://www.pincky.com/ From toomanyatoomany.net Sat Jun 2 08:10:04 2007 From: toomanyatoomany.net (TooMany Secrets) Date: Sat, 2 Jun 2007 17:10:04 +0200 Subject: [bcn-pm] Test pm.org In-Reply-To: <391e184c0706011507m6af6de83vdad664ab0adb8f3e@mail.gmail.com> References: <391e184c0706011507m6af6de83vdad664ab0adb8f3e@mail.gmail.com> Message-ID: 2007/6/2, Joel Pinckheard : > -- > Joel Pinckheard http://www.pincky.com/ Si, funcionar funciona, pero el tráfico es ya otro asunto... xDD -- Have a nice day ;-) TooManySecrets ============================ Nine megs for the secretaries fair, Seven megs for the hackers scarce, Five megs for the grads in smoky lairs, Three megs for system source; One disk to rule them all, One disk to bind them, One disk to hold the files And in the darkness grind 'em. ============================ From joel.pinckheardagmail.com Wed Jun 13 04:44:03 2007 From: joel.pinckheardagmail.com (Joel Pinckheard) Date: Wed, 13 Jun 2007 13:44:03 +0200 Subject: [bcn-pm] yapc-na 2007 is almost here In-Reply-To: <20070613113744.EC223478088@ws1-5.us4.outblaze.com> References: <20070613113744.EC223478088@ws1-5.us4.outblaze.com> Message-ID: <391e184c0706130444s3e8dd884kdc98e77147f33602@mail.gmail.com> From: "Jeremy Fluhmann" Subject: [pm_groups] yapc-na 2007 is almost here Date: Tue, 12 Jun 2007 00:07:48 -0500 Please disseminate to your Perl Monger groups and any other groups that you are a part of that may be interested in attending. YAPC::NA 2007 is only 13 days away! If you haven't already registered, it's not too late! Visit the YAPC::NA website (http://conferences.mongueurs.net/yn2007) to get registered. Don't miss out on the largest Perl gathering of North America! On campus housing wants final numbers on June 15. Don't wait until the last minute! ACT now! For one easy payment of just $100 you'll get: Three days packed with 36 hours of talks Opportunities to meet various members of the Perl community Chance to attend a variety of Birds of a Feather sessions (BOFs) Conference T-shirt Swag bag full of all sorts of goodies (including a particular Perl magazine) A night of gaming fun and Glow Bowling at the UC Games Room (more information coming soon) Dinner at the Tuesday night Banquet - Texas Barbecue themed Face time with potential employers at the Job Fair Updates on major Perl projects Keynotes by The Perl Foundation and Larry Wall himself Plus, for $200 more dollars, we'll throw in two extra days of Perl! That's right, following the conference, Stonehenge is offering two 2-day training sessions at prices well under market value. brian d foy will be offering two days of Intermeidate Perl with Randal Schwartz covering Perl Best Practices and Persistent Perl Data. Visit the Master Class page on the YAPC to find out more - http://conferences.mongueurs.net/yn2007/master.html Don't have $200, but still want more Perl? Then stay for the Hackathon! Two days of hacking fun and helping out on various projects. There's a wiki page on the site for signing up - http://conferences.mongueurs.net/yn2007/wiki?node=Hackathon See you in Houston! Thanks, Jeremy From blas.gordonagmail.com Wed Jun 13 06:48:33 2007 From: blas.gordonagmail.com (Enrique Nell) Date: Wed, 13 Jun 2007 15:48:33 +0200 Subject: [bcn-pm] Complejidad de algoritmos Message-ID: Hola Al leer las diapositivas de una de las charlas de la YAPC::NA::2007, http://www.mawode.com/~waltman/talks/approx_ppw.pdf, me he acordado de algo a lo que empecé a dar vueltas recientemente, aunque no me siento preparado para abordar el problema. ¿Conocéis alguna manera de realizar una estimación del tiempo que tardará en ejecutarse un algoritmo basada en la memoria requerida por las estructuras de datos de partida, la memoria RAM disponible y la velocidad del procesador? Sería algo así como hacer un benchmark aproximado a priori que permita, por ejemplo, dar al usuario de un programa la posibilidad de elegir ejecutar o no una función según el tiempo de ejecución estimado para los datos en cuestión. Como no tengo apenas conocimientos sobre complejidad algorítmica, lo primero que se me ocurrió fue usar un enfoque empírico: medir tiempos de referencia para estructuras de datos de distintos tamaños en una máquina y utilizar ese test kit para medir los valores correspondientes durante la configuración del programa en otra máquina, a fin de extrapolar los tiempos para una máquina con memoria y velocidad de procesador distintas, pero sospecho que no debe de ser tan sencillo y, entre otras cosas, dependerá de la complejidad de los algoritmos (vamos, que creo que no me libraré de medirla). Agradeceré todas las pistas y referencias de lectura que podáis darme. Saludos Enrique From alexmaalexm.org Wed Jun 13 15:53:02 2007 From: alexmaalexm.org (Alex Muntada) Date: Thu, 14 Jun 2007 00:53:02 +0200 Subject: [bcn-pm] Complejidad de algoritmos In-Reply-To: References: Message-ID: <35064d940706131553o3cdca6dy8ea44028e089dc02@mail.gmail.com> * Enrique Nell : > ¿Conocéis alguna manera de realizar una estimación del tiempo que > tardará en ejecutarse un algoritmo basada en la memoria requerida por > las estructuras de datos de partida, la memoria RAM disponible y la > velocidad del procesador? Jo conec un profiler que segurament no és tan potent com el que tu vols però que potser et serveix per començar (és útil per saber en quins punts del codi es perd més temps i per tant quins punts caldria optimitzar): http://search.cpan.org/dist/DProf/ Hi ha d'altres eines de benchmark al CPAN: http://search.cpan.org/search?query=benchmark -- Alex Muntada http://alexm.org/ From explorerajoaquinferrero.com Wed Jun 13 16:32:51 2007 From: explorerajoaquinferrero.com (Joaquin Ferrero) Date: Thu, 14 Jun 2007 01:32:51 +0200 Subject: [bcn-pm] Complejidad de algoritmos In-Reply-To: References: Message-ID: <1181777571.6149.20.camel@portatil.aprosi.net> El mié, 13-06-2007 a las 15:48 +0200, Enrique Nell escribió: > ¿Conocéis alguna manera de realizar una estimación del tiempo que > tardará en ejecutarse un algoritmo basada en la memoria requerida por > las estructuras de datos de partida, la memoria RAM disponible y la > velocidad del procesador? Sería algo así como hacer un benchmark > aproximado a priori que permita, por ejemplo, dar al usuario de un > programa la posibilidad de elegir ejecutar o no una función según el > tiempo de ejecución estimado para los datos en cuestión. Te falta una pata para formar la mesa: el sistema operativo. Mira aquí, vete a la parte del programa de prueba y sorpréndete: http://perlenespanol.baboonsoftware.com/foro/viewtopic.php?t=1645 Donde yo estoy manejamos grandes estructuras de datos (hashes y arrays a múltiples niveles). Bueno, pues llega un momento en que Perl devora toda la memoria y Windows comienza el swap, y de allí podemos irnos a tomar el café, etc. Yo sospecho que el problema es que, aunque yo le pido continuamente a Perl que libere la memoria de las estructuras de datos temporales, esa memoria no es devuelta al sistema por estar compuesta de millones de pequeñas zonas de memoria reservada, y el sistema renuncia a recuperarlas por ser un proceso costoso (creo que en Linux hay algo parecido). Al final, en algunas situaciones hemos tenido que usar DBM::Deep. Más lento (no nos importa), pero el espacio ya es el del disco duro. En procesos largos solemos poner barras de progreso basadas en Smart::Comments (pero con mucha moderación, porque el cálculo de la propia barra consume muchos recursos) Así al menos el usuario sabe más o menos cuánto tiempo va a tardar en terminarse. Yo creo que podrías resolver el problema guardando un histórico de tiempos... y siempre y cuando las condiciones externas sean las mismas (otros programas ejecutándose, otros usuarios trabajando en la máquina, interrupciones externas del hardware, etc. etc). En mi anterior trabajo en la universidad tardábamos 140 minutos en procesar una imagen vía satélite. El jefe compró una máquina con dos procesadores. Bueno, pues lanzando dos imágenes a la vez tardaba entre 4 o 5 horas. El problema estaba en que los procesos "competían" por el acceso a la memoria y a los discos. Al final, se creo una cola de procesado, y se bajó a 100 minutos. Más tarde se compró un cluster de 8 nodos y se consiguió bajar a menos de 20 minutos, pero porque cada nodo procesaba una parte de la imagen (se dividió el problema). -- JoaquinFerrero.com Linux User #109802 msn/jab explorer en jab.pucela.net GPG/PGP 0x42DDB1FE From blas.gordonagmail.com Thu Jun 14 02:30:30 2007 From: blas.gordonagmail.com (Enrique Nell) Date: Thu, 14 Jun 2007 11:30:30 +0200 Subject: [bcn-pm] Complejidad de algoritmos In-Reply-To: <35064d940706131553o3cdca6dy8ea44028e089dc02@mail.gmail.com> References: <35064d940706131553o3cdca6dy8ea44028e089dc02@mail.gmail.com> Message-ID: Hola Alex > Jo conec un profiler que segurament no és tan potent com el que > tu vols però que potser et serveix per començar (és útil per saber > en quins punts del codi es perd més temps i per tant quins punts > caldria optimitzar): http://search.cpan.org/dist/DProf/ Sí, pero lo que me interesa es obtener una estimación del tiempo aproximado que tardará en ejecutarse un algoritmo, independientemente de su eficiencia. Por ejemplo, si hago un programa que realiza algún tipo de operación con arrays de cadenas y lo pruebo con tamaños de arrays razonables, quiero poder indicar al típico individuo arrojado (como yo en mi juventud) cuánto tardará en procesar un tamaño razonable x 1000 antes de que lo intente, por si no le conviniera, o directamente impedírselo. Enric From blas.gordonagmail.com Thu Jun 14 03:02:14 2007 From: blas.gordonagmail.com (Enrique Nell) Date: Thu, 14 Jun 2007 12:02:14 +0200 Subject: [bcn-pm] Complejidad de algoritmos In-Reply-To: <1181777571.6149.20.camel@portatil.aprosi.net> References: <1181777571.6149.20.camel@portatil.aprosi.net> Message-ID: Hola Joaquín > Te falta una pata para formar la mesa: el sistema operativo. > Mira aquí, vete a la parte del programa de prueba y sorpréndete: > http://perlenespanol.baboonsoftware.com/foro/viewtopic.php?t=1645 Cierto, esto complica todavía más el problema. Para empezar me conformaría con lograr controlar los tiempos para un número reducido de sistemas (tendría que hacer benchmarks independientes para cada uno de ellos). > Al final, en algunas situaciones hemos tenido que usar DBM::Deep. Más > lento (no nos importa), pero el espacio ya es el del disco duro. Esto está en mi lista de tareas pendientes. Aún no he podido leer el artículo sobre DBM::Deep que sale en el número pasado de The Perl Review. > En procesos largos solemos poner barras de progreso basadas en > Smart::Comments (pero con mucha moderación, porque el cálculo de la > propia barra consume muchos recursos) Así al menos el usuario sabe más o > menos cuánto tiempo va a tardar en terminarse. Muy interesante. No lo conocía. > Yo creo que podrías resolver el problema guardando un histórico de > tiempos... y siempre y cuando las condiciones externas sean las mismas > (otros programas ejecutándose, otros usuarios trabajando en la máquina, > interrupciones externas del hardware, etc. etc). Muchas gracias por la información. Enrique From salvafgaterra.es Thu Jun 14 03:28:37 2007 From: salvafgaterra.es (=?ISO-8859-1?Q?Salvador_Fandi=F1o?=) Date: Thu, 14 Jun 2007 12:28:37 +0200 Subject: [bcn-pm] Complejidad de algoritmos In-Reply-To: References: <35064d940706131553o3cdca6dy8ea44028e089dc02@mail.gmail.com> Message-ID: <46711855.9090107@terra.es> Enrique Nell wrote: > Hola Alex > >> Jo conec un profiler que segurament no és tan potent com el que >> tu vols però que potser et serveix per començar (és útil per saber >> en quins punts del codi es perd més temps i per tant quins punts >> caldria optimitzar): http://search.cpan.org/dist/DProf/ > > Sí, pero lo que me interesa es obtener una estimación del tiempo > aproximado que tardará en ejecutarse un algoritmo, independientemente > de su eficiencia. Por ejemplo, si hago un programa que realiza algún > tipo de operación con arrays de cadenas y lo pruebo con tamaños de > arrays razonables, quiero poder indicar al típico individuo arrojado > (como yo en mi juventud) cuánto tardará en procesar un tamaño > razonable x 1000 antes de que lo intente, por si no le conviniera, o > directamente impedírselo. Hola Enrique, Puedes, establecer un modelo matematico para la complejidad de tu algoritmo y con algunos benchmarks ajustarlo. Por ejemplo, si tienes un script que ordena algo, tipicamente su complejidad sera O(NlogN), osea, que el tiempo que tardara en ejecutarse es una funcion t(n) = A + B * n + C * n log n Si mides los tiempos de ejecucion del script para distintos valores de n, tendras un conjunto de pares (n1, t1), (n2, t2)...(nm, tm) con los cuales podras ajustar los valores de A, B y C minimizando el error. Luego, podras calcular el tiempo de ejecucion estimado de tu script, sin mas que calcular t(n) para el n que quieras. De todas formas, al final se trata de una extrapolacion, y como el modelo matematico utilizado es muy simple los resultados solo seran validos en un entorno limitado. Osea, que si haces benchmarks para n = 1, 2, 4, 8, 16, 32, 64 y 128, probablemente, el resultado que obtengas para n = 256, 512 o 1024 no se aleje mucho de la realidad, pero para n = 1_000_000 es probable que no tenga nada que ver. Tambien tienes que considerar que como comentaban en otro correo, los tama~nos de memoria de cache, RAM y swap tambien afectan a la velocidad de un algoritmo. La misma aproximacion que comentaba antes puede ser utilizada para estimar el consumo de memoria. - Salva > > Enric > _______________________________________________ > llista dels Barcelona-pm > Barcelona-pm en pm.org > http://mail.pm.org/mailman/listinfo/barcelona-pm > BCN Perl Mongers: http://barcelona.pm.org > From blas.gordonagmail.com Thu Jun 14 06:48:01 2007 From: blas.gordonagmail.com (Enrique Nell) Date: Thu, 14 Jun 2007 15:48:01 +0200 Subject: [bcn-pm] Complejidad de algoritmos In-Reply-To: <46711855.9090107@terra.es> References: <35064d940706131553o3cdca6dy8ea44028e089dc02@mail.gmail.com> <46711855.9090107@terra.es> Message-ID: Gracias, probaré algo así. Enrique > Hola Enrique, > > Puedes, establecer un modelo matematico para la complejidad de tu > algoritmo y con algunos benchmarks ajustarlo. > > Por ejemplo, si tienes un script que ordena algo, tipicamente su > complejidad sera O(NlogN), osea, que el tiempo que tardara en ejecutarse > es una funcion > > t(n) = A + B * n + C * n log n > > Si mides los tiempos de ejecucion del script para distintos valores de > n, tendras un conjunto de pares (n1, t1), (n2, t2)...(nm, tm) con los > cuales podras ajustar los valores de A, B y C minimizando el error. > > Luego, podras calcular el tiempo de ejecucion estimado de tu script, sin > mas que calcular t(n) para el n que quieras. > > De todas formas, al final se trata de una extrapolacion, y como el > modelo matematico utilizado es muy simple los resultados solo seran > validos en un entorno limitado. Osea, que si haces benchmarks para n = > 1, 2, 4, 8, 16, 32, 64 y 128, probablemente, el resultado que obtengas > para n = 256, 512 o 1024 no se aleje mucho de la realidad, pero para n = > 1_000_000 es probable que no tenga nada que ver. > > Tambien tienes que considerar que como comentaban en otro correo, los > tama~nos de memoria de cache, RAM y swap tambien afectan a la velocidad > de un algoritmo. La misma aproximacion que comentaba antes puede ser > utilizada para estimar el consumo de memoria. > > - Salva From jluisaescomposlinux.org Fri Jun 15 03:27:28 2007 From: jluisaescomposlinux.org (=?iso-8859-1?q?Jos=E9_Luis_P=E9rez_Diez?=) Date: Fri, 15 Jun 2007 12:27:28 +0200 Subject: [bcn-pm] Complejidad de algoritmos In-Reply-To: References: <35064d940706131553o3cdca6dy8ea44028e089dc02@mail.gmail.com> Message-ID: <200706151227.29574.jluis@escomposlinux.org> On Thursday 14 June 2007 11:30, Enrique Nell wrote: > Sí, pero lo que me interesa es obtener una estimación del tiempo > aproximado que tardará en ejecutarse un algoritmo, independientemente > de su eficiencia. Por ejemplo, si hago un programa que realiza algún > tipo de operación con arrays de cadenas y lo pruebo con tamaños de > arrays razonables Yo habia pensado en usar un profiler que cuente las veces que se ejecutan puntos del algoritmo y realizar una cuenta de estas operaciones. usar esas cuentas tres grupos de datos de tamaños n 2n y 4n e intentarlos ajustar a una curva usando logaritmos para aplanar la curva si es necesario. Usar estos datos para predecir el tiempo usando la curva f(n) y en el caso de superar el 80% de la memoria disponible añadir el tiempo que tardaria el resto multipiclado por una constante C para contabilizar la swap si m (memoria) es 10 y n 20 el tiempo seria f(20) +f(12)*C+f(4)*C. Esto creo que te daria estimaciones que asusten a los valientes. From blas.gordonagmail.com Fri Jun 15 05:56:34 2007 From: blas.gordonagmail.com (Enrique Nell) Date: Fri, 15 Jun 2007 14:56:34 +0200 Subject: [bcn-pm] Complejidad de algoritmos In-Reply-To: <200706151227.29574.jluis@escomposlinux.org> References: <35064d940706131553o3cdca6dy8ea44028e089dc02@mail.gmail.com> <200706151227.29574.jluis@escomposlinux.org> Message-ID: También lo investigaré. Muchas gracias. Enrique On 6/15/07, José Luis Pérez Diez wrote: > On Thursday 14 June 2007 11:30, Enrique Nell wrote: > > Sí, pero lo que me interesa es obtener una estimación del tiempo > > aproximado que tardará en ejecutarse un algoritmo, independientemente > > de su eficiencia. Por ejemplo, si hago un programa que realiza algún > > tipo de operación con arrays de cadenas y lo pruebo con tamaños de > > arrays razonables > > Yo habia pensado en usar un profiler que cuente las veces que se ejecutan > puntos del algoritmo y realizar una cuenta de estas operaciones. > > usar esas cuentas tres grupos de datos de tamaños n 2n y 4n e intentarlos > ajustar a una curva usando logaritmos para aplanar la curva si es necesario. > > Usar estos datos para predecir el tiempo usando la curva f(n) y en el caso > de superar el 80% de la memoria disponible añadir el tiempo que tardaria el > resto multipiclado por una constante C para contabilizar la swap > si m (memoria) es 10 y n 20 > > el tiempo seria f(20) +f(12)*C+f(4)*C. > > Esto creo que te daria estimaciones que asusten a los valientes. > > > _______________________________________________ > llista dels Barcelona-pm > Barcelona-pmapm.org > http://mail.pm.org/mailman/listinfo/barcelona-pm > BCN Perl Mongers: http://barcelona.pm.org > From jluisaescomposlinux.org Mon Jun 25 23:54:50 2007 From: jluisaescomposlinux.org (=?iso-8859-1?q?Jos=E9_Luis_P=E9rez_Diez?=) Date: Tue, 26 Jun 2007 08:54:50 +0200 Subject: [bcn-pm] Este jueves toca quedada Message-ID: <200706260854.52594.jluis@escomposlinux.org> ¿Se superara el numero de 3 reunidos récord absoluto de los últimos meses? From blas.gordonagmail.com Tue Jun 26 13:42:48 2007 From: blas.gordonagmail.com (Enrique Nell) Date: Tue, 26 Jun 2007 22:42:48 +0200 Subject: [bcn-pm] Este jueves toca quedada In-Reply-To: <200706260854.52594.jluis@escomposlinux.org> References: <200706260854.52594.jluis@escomposlinux.org> Message-ID: Hola Este mes no puedo ir, pero sí iré el mes que viene. Si hubiera interés y no hay otra charla programada, para la reunión de julio podría preparar una charla/demo sobre un programa que creé hace unos meses para integrar en los clientes de chat la capacidad de traducir de castellano a catalán y viceversa mediante un traductor automático online. Saludos Enrique On 6/26/07, José Luis Pérez Diez wrote: > > ¿Se superara el numero de 3 reunidos récord absoluto de los últimos meses? > _______________________________________________ > llista dels Barcelona-pm > Barcelona-pmapm.org > http://mail.pm.org/mailman/listinfo/barcelona-pm > BCN Perl Mongers: http://barcelona.pm.org > From fxnahashref.com Tue Jun 26 14:54:26 2007 From: fxnahashref.com (Xavier Noria) Date: Tue, 26 Jun 2007 23:54:26 +0200 Subject: [bcn-pm] Este jueves toca quedada In-Reply-To: References: <200706260854.52594.jluis@escomposlinux.org> Message-ID: On Jun 26, 2007, at 10:42 PM, Enrique Nell wrote: > Este mes no puedo ir, pero sí iré el mes que viene. Si hubiera interés > y no hay otra charla programada, para la reunión de julio podría > preparar una charla/demo sobre un programa que creé hace unos meses > para integrar en los clientes de chat la capacidad de traducir de > castellano a catalán y viceversa mediante un traductor automático > online. No hay nada programado, adjudicada! -- fxn From sergioacodigo.com Wed Jun 27 02:36:07 2007 From: sergioacodigo.com (Sergio Arias) Date: Wed, 27 Jun 2007 11:36:07 +0200 Subject: [bcn-pm] Propuesta para Este jueves q toca quedada In-Reply-To: <200706260854.52594.jluis@escomposlinux.org> References: <200706260854.52594.jluis@escomposlinux.org> Message-ID: <1182936967.2146.79.camel@localhost> El dt 26 de 06 del 2007 a les 08:54 +0200, en/na José Luis Pérez Diez va escriure: > ¿Se superara el numero de 3 reunidos récord absoluto de los últimos meses? No llames al mal tiempo... Por cierto, en perl prima la calidad sobre la cantidad :P Para conseguir mayor asistencia tendríamos que plantear algún tema apetitoso. Aunque no haya nadie protagonizando una presentación. Con las pequeñas aportaciones que cada uno haga puede resultar interesante. Creo que la falta de concreción ha hecho disminuir el interés del grupo. Hace pocos meses presencié como el coloquio improvisado derivaba hacia una obcecada confrontación lingüística. (ggg, menua frase ma'qedao, releer detenidamente). Para mantener el buen rollete del grupo, o básicamente para que continúe existiendo, sería deseable que no se volvieran a repetir discusiones personales. Ojo, me lo digo a mí, sin intención de amonestar o molestar a nadie, porque me pesa no haberlo tenido claro mientras ocurría y no haber mediado en consecuencia cuando pude hacerlo. Propuesta para tratar mañana; La Administración Electrónica® No es un tema muy perlero. Es más político que técnico. Intuyo que nos interesará, sobretodo por estar muy de moda. Con toda una señora Ley recién sacada del horno. ¿Qué opinais? Salut! From alexmaalexm.org Wed Jun 27 02:40:04 2007 From: alexmaalexm.org (Alex Muntada) Date: Wed, 27 Jun 2007 11:40:04 +0200 Subject: [bcn-pm] Este jueves toca quedada In-Reply-To: References: <200706260854.52594.jluis@escomposlinux.org> Message-ID: <35064d940706270240m6afd5e58kc88c3c449986300f@mail.gmail.com> * Enrique Nell : > Este mes no puedo ir, pero sí iré el mes que viene. Jo estic igual. > Si hubiera interés y no hay otra charla programada, para > la reunión de julio podría preparar una charla/demo sobre > un programa que creé hace unos meses para integrar en > los clientes de chat la capacidad de traducir de castellano > a catalán y viceversa mediante un traductor automático > online. Tinc molt interès en aquest tema. -- Alex Muntada http://alexm.org/ From toomanyatoomany.net Wed Jun 27 04:04:44 2007 From: toomanyatoomany.net (TooMany Secrets) Date: Wed, 27 Jun 2007 13:04:44 +0200 Subject: [bcn-pm] Propuesta para Este jueves q toca quedada In-Reply-To: <1182936967.2146.79.camel@localhost> References: <200706260854.52594.jluis@escomposlinux.org> <1182936967.2146.79.camel@localhost> Message-ID: El 27/06/07, Sergio Arias escribió: > Propuesta para tratar mañana; La Administración Electrónica(r) > No es un tema muy perlero. Es más político que técnico. Intuyo que nos > interesará, sobretodo por estar muy de moda. Con toda una señora Ley > recién sacada del horno. > ¿Qué opinais? Yo ayer me compilé e instalé el "pugs" (Perl6), para ir comenzando a tener una primera toma de contacto con él. Así que aunque no sea un versado en Perl como vosotros, considero que estaría guapa una exposición sobre Perl 6. Estoy comenzando la introducción a partir del documento éste: http://www.pair.com/~comdog/Talks/LearningPerl6-NPW2007.pdf Tengo difícil poder asistir, pero ese sería uno de mis temas favoritos. Bueno, ese o que se hiciese una charla realmente constructiva sobre Perl vs Ruby (y lo digo claro; constructiva, nada de fanatismos de fan-boy). -- Have a nice day ;-) TooManySecrets ============================ Dijo Confucio: "Exígete mucho a ti mismo y espera poco de los demás. Así te ahorrarás disgustos." ============================ From jdelgadoalsi.upc.edu Thu Jun 28 14:20:04 2007 From: jdelgadoalsi.upc.edu (Jordi Delgado) Date: Thu, 28 Jun 2007 23:20:04 +0200 Subject: [bcn-pm] Links interessants / curiosos In-Reply-To: References: Message-ID: <20070628212004.GA28130@nodoiuna.lsi.upc.edu> Hola, Avui a la reunio he mencionat un parell de coses que poden ser d'interes: - Com es fa el software de l'Space Shuttle?: http://www.fastcompany.com/online/06/writestuff.html Jo ho he trobat molt interssant... - Joc molt addictiu: http://www.albinoblacksheep.com/games/bloxorz Si llegiu les instruccions us semblara mes complicat del que realment es, llegiu-les en diagonal i "seguid vuestro instinto, pequenos padawans" No cal dir que no em faig responsable de les consequencies de la vostra addiccio (procrastinators rule the world!). Salut! Jordi From blas.gordonagmail.com Thu Jun 28 14:42:33 2007 From: blas.gordonagmail.com (Enrique Nell) Date: Thu, 28 Jun 2007 23:42:33 +0200 Subject: [bcn-pm] Propuesta para Este jueves q toca quedada In-Reply-To: References: <200706260854.52594.jluis@escomposlinux.org> <1182936967.2146.79.camel@localhost> Message-ID: > Yo ayer me compilé e instalé el "pugs" (Perl6), para ir comenzando a > tener una primera toma de contacto con él. Así que aunque no sea un > versado en Perl como vosotros, considero que estaría guapa una > exposición sobre Perl 6. Posiblemente te interese esta noticia: http://use.perl.org/articles/07/06/26/2159246.shtml Saludos Enrique From toomanyatoomany.net Thu Jun 28 23:10:51 2007 From: toomanyatoomany.net (TooMany Secrets) Date: Fri, 29 Jun 2007 08:10:51 +0200 Subject: [bcn-pm] Propuesta para Este jueves q toca quedada In-Reply-To: References: <200706260854.52594.jluis@escomposlinux.org> <1182936967.2146.79.camel@localhost> Message-ID: El 28/06/07, Enrique Nell escribió: > Posiblemente te interese esta noticia: > > http://use.perl.org/articles/07/06/26/2159246.shtml Si, la leí este fin de semana pasado cuando me llegaron las "Perl news". Es muy interesante, si señor ;-) Gracias! -- Have a nice day ;-) TooManySecrets ============================ Dijo Confucio: "Exígete mucho a ti mismo y espera poco de los demás. Así te ahorrarás disgustos." ============================